Fail-over VPN site-to-site

[BigPalo]

Hi,

We have a PA with two VPNs configured. VPN-Main is the active one and if this vpn falls, the traffic must go through the other VPN-backup. The fact is that when the active VPN falls, the route that has the Palo Alto continues going through the previous VPN, it does not refresh the route and adds it through the new tunnel.

This configuration worked when this deployment was done but suddenly stop working.

We have configured a tunnel monitor with destination IP and profile fail-over.

In VPN Main (active):

In VPN (backup):

And this is the route table:

tunnel.29 is the main (active). The metric is 2.

tunnel.27 is the backup. Metric is 5.

Why PA is not deleting the "active" route if the monitor ip is down through the vpn down.

[LukaPecher]

Hi @aleksandar.astardzhiev 

We have the same problem with failover VPN. We have 6 proxy IDs in the tunnel and the primary ipsec tunnel drops. You explained why it drops and now I am interested if you have maybe any solution for that problem?

BR

[aleksandar.astardzhiev]

Hi @LukaPecher,

My solution was to split the proxy-id into separate IPsec tunnel configuration. It may sound very confusing, so I will try to explain it as clear as possible:

- You will need four ipsec tunnel - two tunnel to primary remote peer and two tunnel to secondary remote peer

- First two tunnels must be assigned with same tunnel interface (let say tunnel.1) and same IKE gateway (remote peer)

- Second two tunnels also must be assigned to same tunnel interface - tunnel.2 and same remote peer

- First primary tunnel will be configure with tunnel monitor enabled and with only one proxy-id that match the source and dest of the monitor

- Second primary tunnel will be configured with tunnel monitor disabled and with as many proxy-id as you like/need, excluding the proxy-id configured in the first primary

Identical you need to configure the second two tunnels to the secondary remote peer.

So under Network > IPsec Tunnels you should have something like that:

That way the tunnel monitor will send pings only via the correct proxy-id.

If the pings fail (for what ever reason), tunnel monitor will bring the logical tunnel interface. And because we are using the same tunnel interface for the second tunnel (to the primary peer without monitor), all the routes to tunnel.1 will be remove from FIB and traffic wil be redirected to secondary tunnel.

[treese]

How would pbf work with VPN.  I thought VPN traffic you could use pbf?

Thank you

[OtakarKlier]

Hello,

Yes PBF can work. You would set the static route to the secondary tunnel and the PBF would point at the primary VPN with a tunnel monitor and disable of the policy.

The PBF takes effect prior to the Virtual Router, so if the PBF is disabled because of primary VPN down and tunnel monitor, the Virtual router then uses the static route that points at the secondary VPN tunnel.

Hope this helps.

[treese]

Ok in my situation I have 1 VPN tunnel as backup and the primary fiber circuit lives on our core switchs.  The VPN tunnel points to the VIP on our cores until I manually change routes on the Palo to move to vpn when fiber circuit failure occur.  The other side isn't owned by us and don't support BFD.  I have a flow direct set on cores to remove the primary route (when unavailable) and send the traffic to the FW to engage the VPN but the FW routes are static and trying to decide to use PBF if possible to switch the traffic.  The VIPs on cores won't ever go down and looked at tunnel monitoring and path monitoring too but not sure how well it would work with only one VPN tunnel and the primary route to the core VIP.  All thoughts are welcome.  Thank you

[treese]

Spoiler

I found that static route path monitoring is what I need with this situation.  Thanks for your help.

[VTQNetwork]

To avoid tunnel flaps with multiple Proxy-IDs defined, it is possible to specify which Proxy-ID should be used:

set network tunnel ipsec TUNNEL tunnel-monitor destination-ip 192.168.1.1 tunnel-monitor-profile tunnel-monitor-failover proxy-id XXX