GRE Tunnel to Zscaler failover

[smshafek]

Hello,

I have two Destination IPs (one for each GRE Tunnel to Zscaler). How would I need to configure my palo alto firewall to allow GRE Tunnel Failover, so that traffic only flows through the primary tunnel and flows through the secondary tunnel when the first one fails?

Thanks!

[aleksandar.astardzhiev · Accepted solution]

Hi @smshafek 

The last time I had to deal with tunnels to Zscaler was before the GRE Tunnel support on Palo Alto FWs, so I haven't tested this personally. Can you please clarify for me:

- Are you using IPsec encryption - GRE over IPsec? Or it is pure GRE without IPsec.

- How have you configured the routing for traffic over the tunnels at the moment?

- Did you deployment is something similar - https://community.zscaler.com/t/gre-tunnel-from-palo-alto-firewall/8024/2

Assume you are using pure GRE without IPsec:

- You need to enable GRE keepalive under each tunnel

- Create two static routes with different metric

GRE keepalive will "disbale" the tunnel interface when it detects issues with the GRE tunnel. This on other hand will "disable" the static route pointing to that tunnel, which means firewall will use the second route. Upon primary GRE tunnel recovery, the primary static route will be available again and since it has lower metric, firewall will automatically switch to it.

Note: in the link above they are using PBF rules (I still don't get why people love to make their live miserable with PBF...) instead of static routes. In this case you need to use PBF path-monitor instead of relying on the GRE keepalives.

[smshafek]

Hi @aleksandar.astardzhiev ,

Thanks for the reply. I'm using pure GRE with no IPsec and I was following the documentation from zscaler.

The failover works now. It seems the solution is either, PBF and path monitor, OR keepalives. My configuration was as such that both path monitor and keepalives were active and it didn't work out. I've also configured the two static routes with different metrics.

On a side note, why is there PBF anyway?

Thanks again for the reply, it was really helpful.

[aleksandar.astardzhiev]

Hi @smshafek ,

I am also wondering why people still suggesting the use of PBF for tunnel (IPsec to GRE) failover,... I am only guessing that this was the way long, long ago with earlier version of PanOS.

GRE keepalives wouldn't affect PBF routing, because PBF rules are enforced the same way as security - first match top to bottom. No matter if the tunnel is down and the next-hop is not available. Enabling path monitor in PBF rule, will disable that rule if the ping probes don't receive replies. But this is true, only if you use "fail-over" for monitoring profile, "wait-recover" will have different effect - https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/policy/policy-based-forwarding/pbf/path-mo...

So PBF rules with path-monitor and "fail-over" monitor profile, should work as well.

Anyway, I always recommend to stay away from PBF whenever possible, so should stick with the static routes with different metric and GRE keepalives.

[jamessciortino]

The PBF solution is helpful in an existing Palo design where you already have a default route (or two) for your campus LAN networks.

Consider that you need to swing specific subnets or VLANs to Zscaler GRE overtime -- you don't want to do an all-or-nothing migration for your entire site, but instead wish to surgically move each subnet over to the GRE tunnel one-by-one. Or, perhaps you want your Guest interface to egress directly from the Palo Alto instead of being sent to Zscaler. 

PBF provides a lot of flexibility that you don't have when with static routes. And it's really cool that -- in the absence of PBF rules (for example, if each tunnel monitor fails) you can failover to your routing table. I happen to like it. 

[jamessciortino]

And if anyone reading my above post doesn't realize -- you can specify a source and destination with Policy Based Routes. That's where the flexibility comes from.