PAGroupCft Incorrect Transit VPC Subnet CIDRs

[cronq]

I used a non-default CIDR when deploying the Transit VPC (not 10.100.0.0). When PAGroupCft runs, it outputs the correct gateways for the Transit VPC AZs, but seems to keep a hard coded 10.100.0.0/27 and 10.100.0.32/27 for "transitVpcDmzAz1SubnetCidr" and "transitVpcDmzAz2SubnetCidr". Does this have any downstream impact or should these 2 values be removed from the PAGroupCft template?

[narayan-iyengar]

I think those values can be removed..copy paste error

[freimer]

Those parameters are not even used anywhere in the CFT for paGroupCft, other than an Output, so they can be removed and/or ignored.

[freimer]

Upon further investigation, it looks like the subnet CIDR and gateway is "pass through" to the Outputs of the CF stack, and those Outputs are used in configuring the firewall. The gateway is used "directly," but the CIDR is broken out and only the bits or "part after the /" is used in configuring the firewall IPs. So if your public CIDR is anything other than a /27 it will probably be configured incorrectly unless you specify the correct CIDR when spinning up the paGroupCft. However, "you" don't spin it up, the automation does. Let me find what does that...

createNewPaGroup in pan_vpn_generic.py. This is called by createNewPaGroupLambda.py, and it only passes the transitVpcDmzAz1SubnetGateway and transitVpcDmzAz2SubnetGateway, not even passing the transitVpcDmzAz1SubnetCidr and transitVpcDmzAz2SubnetCidr that the paGroupCft accepts. Perhaps that is because these values are not stored in the DynamoDB table from which it pulls the TransitVPC config info.

In order to get this to work "properly" the CIDRs specified in the intializeTransitAccount.json CFT need to be saved to the DynamoDB table, and passed by the createNewPaGroupLambda.py handler function to the createNewPAGroup function in pan_vpn_generic.py, and then passed to the paGroupCft when the stack is created. The proper values would then be used by paGroupInitialize, which is called by the handler for checkStackStatusLambda function that is fired when the stack is complete.

There are several fixes that need to be implemented. Let me see if I can get this done today or tomorrow.

[freimer]

This should be fixed by #21 commit afc7bbb, testing now.