PaloAltoNetworks / aws-transit-vpc

automated AWS transit vpc
41 stars 34 forks source link

Data Plane CIDR Misconfigured when using mask other than /27 #34

Open brichbourg opened 6 years ago

brichbourg commented 6 years ago

Hello,

I spend quite a few hours on a Palo TAC case troubleshooting an issue with the BGP peers for the Transit solution flapping every few minutes. We finally found the issue yesterday and it was due to the fact that the ARP TTL was expiring for the VPC's default gateway. We realized that the mask was misconfigured on the Palo and didn't match the mask we used for the transit. Our cloud team designed everything with /23s, but a /27 still configured as the mask on the "eth1" network object used for the static IP. The IP address was correct, just not the mask.

I've been trying to disgest the code more to see if I could ID where this issue was occurring. The best I can see given the limited amount of time I have is I noticed in the Cloudwatch logs for checkStackStatusLambda.py the following.

Peering of new PA Group: {'Az2SubnetCidr': '10.100.0.32/27', 'Az2SubnetGw': '10.13.2.1', 'N2Eip': 'X.X.X.X', 'N1Eip': 'Y.Y.Y.Y', 'PaGroupName': 'maskedname', 'Az1SubnetCidr': '10.100.0.0/27', 'N2Pip': '10.13.3.143', 'N1Mgmt': '10.13.9.56', 'N1Pip': '10.13.1.145', 'Az1SubnetGw': '10.13.0.1', 'N1Id': 'i-1234', 'N2Mgmt': '10.13.11.174', 'N2Asn': '64778', 'N2Id': 'i-1234', 'N1Asn': '64777'}

Where are these 10.100.0.32/27 addresses coming from? I did not use those in any parameters when I deployed the CFN, and I noticed that the object name was the SubnetCidr and it happened to be a /27, which I wonder if that is where the solution got a /27 from.

This issue caused some major heartburn for a project I am deploying. Can you guys check the code and mask sure it will configure the correct mask on the PANs?