Here’s a case where customer wants to create BGP over GRE tunnels between Palo Alto Firewall and Aviatrix Transit Gateways. Palo Alto have some articles but not very clear, this blog will serve as a reminder how this is done. Credit to Pranay for helping out the BGP peering part on Palo.
This is a simplified lab environment
- Palo Alto instance need to disable Source/Destination Check
- A loopback IP 192.168.101.101 have been added to Palo Alto
- Aviatrix Transit VPC Subnet Route Table need to be modified so it will send traffic target to 192.168.101.101 towards the eni of Palo’s LAN interface
- Make sure Transit GW and Palo security group are allowing ICMP ping to each other, this helps to make sure basic connectivity is there.
- In Palo create Management Profile to allow ICMP and link the profile to the loopback adapter
- Make sure Palo have return route going through it’s LAN interface, in this example, LAN interface is using DHCP and you can retrieve it’s default gateway from it’s status page:
- Create policy to allow any to any for easier troubleshooting. (Obviously lock down in production)
- Ping from Transit GW to Palo Loopback and vise versa
From Transit GW -> Palo Loopback
From Palo Loopback -> Transit GW
- Enable BGP and setup AS number in Palo. Router ID would be just any IP on the virtual router. Choose Install Route
- In Aviatrix Controller -> Multi-Cloud Transit -> Setup -> External connections, use the loopback IP as the remote gateway address and Check “Over Private Network”, enter Palo’s ASN number
- In Aviatrix Controller -> Site2Cloud -> Setup, select the connection created in last step, then click on Edit
- Suggest you download two configurations, one for CISCO CSR, one for Generic
Sample Cisco CSR configuration
Sample Generic configuration
For GRE tunnels, Cisco’s configuration is a bit more clearly.
You can see the inner IP of each tunnel, and the tunnel source would be Palo’s loopback IP, and tunnel destination would be Aviatrix Transit Primary/HA gateway’s LAN IP
Generic configuration is a bit more busy, since I have high performance encryption enabled, it listed all secondary IP of the Aviatrix Transit GW LAN interface. But the tunnel inside IP is in good order.
- On Palo configure Tunnel interfaces:
Add the corresponding 169.254.x.x/30 inner tunnel IP
Make sure to allow ICMP on the tunnel interface, or GRE keep alive will fail.
Example of tunnel diagnostics if ICMP isn’t allowed on tunnel interface, note it need ICMP against both loopback and tunnel interface
- Create GRE tunnel from Palo, use the same loopback IP to create two tunnels against the LAN interface of Aviatrix Transit Gateways. Use the corresponding tunnel interfaces created earlier
The GRE tunnel should now be up, if not run diagnostics to figure out why
- Configure BGP Peer Group on Palo, use the same 169.254.x.x/30 pair as neighbor to each other.
- Enable ECMP Multiple AS Support as we are using two GRE tunnels
- To confirm if BGP is up
- On Palo -> Virtual Routers -> More Runtime Status
The 10.101.0.0/24 route is learned from Aviatrix Transit, and the range is an Aviatrix Spoke.
- On Aviatrix side:
- Test BGP advertisement from Palo:
- On Palo Alto, create a new loopback interface 192.168.200.200/32, assign the same management profile of allow ICMP ping
- On the default virtual router -> BGP -> Redist Rules -> Add a rule to redistribute 192.168.200.200/32 into ebgp
On Aviatrix side, we can see the route been advertised
Ping from test machine in aviatrix spoke also works