Create BGP over GRE tunnel between Aviatrix Transit and Palo Alto Firewall


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:

Static route:

  • 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

, ,

Leave a Reply

Your email address will not be published.