Dual ISP VPN site to site Tunnel Failover with Static Route Path-Monitoring

Dual ISP VPN site to site Tunnel Failover with Static Route Path-Monitoring

222248
Created On 01/24/20 07:05 AM - Last Modified 01/24/20 09:46 AM


Objective


This document is continuation of the below document.
DUAL ISP REDUNDANCY USING STATIC ROUTES PATH MONITORING FEATURE, FOR TRAFFIC FAILOVER
After setting up DUAL ISP redundancy based on static route path monitoring, this document explains how to setup Site to Site VPN tunnels (IKEv1 and IKEv2) per ISP for redundancy of traffic over the tunnels.

Note : If Dual ISP redundancy is configured using multiple Virtual Routers and PBF, then this document does not apply. 
For use of Multiple VRs for Dual ISP and VPN tunnel redundancy refer the below link.
HOW TO CONFIGURE A PALO ALTO NETWORKS FIREWALL WITH DUAL ISPS AND AUTOMATIC VPN FAILOVER

 


Environment


Topology :
User-added image
Assumptions :
Dual ISP using Static route path monitoring is already configured.
PS Firewall A is running PANOS version 8.0 or above.
ISP1 is the Primary ISP and ISP2 is the secondary ISP. 

Requirement :
All traffic to Remote network 10.44.44.0/24 from 10.34.43.0/24 Local network is encrypted over the site to site VPN tunnels. 
VPN tunnel through the Primary ISP is the Primary tunnel. 
If the VPN over ISP 1 fails, then the Secondary VPN tunnel through the Secondary ISP (ISP2) will pass the traffic to the remote side. 
Once the Primary VPN tunnel recovers the traffic will fall back to the Primary VPN tunnel. 


Procedure


PA firewalls can only be configured for Route Based VPN tunnels. The concept of Policy Based Site to Site VPN tunnel is not available. 
Static routes can be configured through the Tunnel interfaces associated to the VPN tunnels to send traffic. 
In case of one or more Proxy IDs configured, the static routes will still be needed to route traffic through the tunnel. 

Configuration :
This document applies to both IKEv1 and IKEv2 tunnels. The VPN tunnel configuration is not explained in this document. 
You can refer IKEv1 tunnel and IKEv2 tunnel configuration guide to configure them. 
Tunnel.1 is configured for Primary VPN tunnel. 
Tunnel.2 is configured for Secondary VPN tunnel. 
Both tunnel interfaces are configured under Security Zone "L3-VPN"
Network > Interface > Tunnel 
User-added image

Network > IPSec Tunnels 
User-added image

Since both Tunnel interfaces are configured under the same Security zone "L3-VPN", a single security policy from Trust zone to L3-VPN zone should be enough to allow traffic on both the tunnels. 
User-added image

In this case the Peer is a PA firewall and hence it has a tunnel interface as well which can hold IP address. 
Primary Tunnel Interface
Tunnel.1 --> 10.10.10.1/30      Peer Tunnel.1 --> 10.10.10.2/30
Secondary Tunnel Interface
Tunnel.2 --> 10.10.20.1/30      Peer Tunnel.2 --> 10.10.20.2/30

However, if the peer side is a different vendor, then an IP address to monitor over the site to site tunnel will have to be identified to be used on both the methods.
This monitoring traffic will be encrypted over the tunnel. 
The IP address used on the tunnel interface on PA and the destination IP that is monitored will have to be covered by the Local and Remote subnet respectively if Proxy ID configuration is used.

There are two methods to do VPN tunnel traffic automatic failover. Any one of the below methods can be used. 
1. Failover using Tunnel Monitoring
2. Failover using Static Route Path monitoring

In case of "Failover using Tunnel Monitoring", by default PA firewall will forward Ping packets to monitored Destination IP over all the Phase 2 tunnels if multiple proxy-ids are configured. 
This will cause the Tunnel monitoring to fail if the Peer side is unable to send back the replies on all the Phase 2 Tunnels.
To make sure the Tunnel Monitoring traffic is only sent over the Proxy-ID which covers its IPs, refer the below document. 
 TUNNEL MONITORING FOR VPN BETWEEN PALO ALTO NETWORKS FIREWALLS AND CISCO ASA

Failover using Tunnel Monitoring :
Tunnel monitoring feature is used to make sure the VPN tunnel is passing traffic. 
If the VPN tunnel goes down or if there are traffic issues over the VPN, the tunnel monitoring will detect it and will bring the tunnel interface down. 
Thus the route through the Primary tunnel interface tunnel.1 will be removed from the Forwarding table and the route through the Secondary Tunnel interface tunnel.2 will take over. 

Configure a Monitoring Profile.
Network > Network Profiles > Monitor > Add
Make sure "Fail Over" Option is selected.
User-added image

Enable Tunnel Monitor on the IPSec Tunnels
Network > IPSec Tunnels > Primary-Tunnel/Secondary-Tunnel > Enable Tunnel Monitor
Configure the destination IP to be monitored and select the configured Monitor Profile "FailoverProfile".
User-added image

The destination IP for the Secondary Tunnel "Tunnel monitor" would be 10.10.20.2 in this setup. 
Note : For Tunnel monitoring to work the Tunnel Interface will have to be configured with an IP address. 
Once the Primary Tunnel monitoring on the Primary tunnel fails, the tunnel interface status is forced to Down.
Network > IPSec Tunnels 
User-added image

The Route through the tunnel.1 is removed and route through tunnel.2 is installed on the Forwarding Table. 
Network > Virtual routers > Click on "More Runtime Stats" for default > Forwarding Table
User-added image
Once the Traffic through the Primary Tunnel recovers, the tunnel monitoring will come up and the route through tunnel.1 will be installed in the Forwarding table. 

Once the Tunnel monitor is goes DOWN or UP the below logs can be seen under System logs
Monitor > Logs > System
User-added image

Failover using Static Route Path monitoring :
Similar to the route failover done using the Static Route Path monitoring feature on Default route, the routes over the VPN tunnel can also use the same method to failover. 
There are two routes configured for remote network 10.44.44.0/2. 
Primary route with metric 10 is configured through the tunnel.1 interface.
Secondary route with metric 20 is configured through the tunnel.2 interface. 
Network > Virtual Routers > Default > Static Routes
User-added image 

Path monitoring on the Primary VPN route is configured to monitor the remote side tunnel IP 10.10.10.2 sourcing from tunnel.1 interface IP 10.10.10.1.
User-added image

Note : The "Preemptive Hold Time" has been set to 0 so that the route through tunnel 1 recovers as soon as the Primary VPN comes back up. 
The Path monitor will send Ping packets to the specified destination which will be encrypted over the site to site tunnel. 
Once the VPN tunnel goes down or if traffic over the tunnel is not going through; the path monitoring would fail. 
Static Route monitoring will show that the route through the Primary VPN tunnel tunnel.1 as down.
Network > Virtual routers > Click on "More Runtime Stats" for default > Static Route Monitoring
User-added image

This primary route will then be removed from the Forwarding table and the Secondary Tunnel route over tunnel.2 with metric 20 will take over. 
Network > Virtual routers > Click on "More Runtime Stats" for default > Forwarding Table
This can also be checked under 
Network > IPSec Tunnels > "Show Routes"
User-added image

> show routing fib

--------------------------------------------------------------------------------
virtual-router name: default

id      destination           nexthop            flags  interface          mtu 
--------------------------------------------------------------------------------
131     0.0.0.0/0             10.75.34.11        ug     ethernet1/5        1500
132     10.44.44.0/24         0.0.0.0            u      tunnel.2           1500
 

The failure and recovery of the Static route path monitoring will generate system logs as below.
Monitor > Logs > System
User-added image
 



Additional Information



Related Links :
HOW TO CONFIGURE IPSEC VPN
DUAL ISP REDUNDANCY USING STATIC ROUTES PATH MONITORING FEATURE, FOR TRAFFIC FAILOVER

 


Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000POO0CAO&lang=en_US&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail