Dual ISP VPN failover with single VR

[Colin_Mutch]

Hi All, looking for some assistance to configure VPN failover for DR/BCP.

I've attached a basic diagram below

Currently, static route monitoring is set up on the outside interfaces of the firewalls at Site A, so if upstream from Site A ISP 1 fails Site A will use Site A ISP 2 to start forwarding traffic out.

From Site A we have two VPN tunnels built to allow Site A LAN to Site B LAN, Site B is also allowed to Site A using the same tunnels.

If Site A ISP 1 fails and we swap across to Site A ISP 2, is there a method to bring up the Site A ISP 2 Tunnel 2 automatically without having an IP assigned to the interface?

Site A already has static routing to Site B via the second tunnel, with a higher metric.

Ideally, I would like Site A to monitor (from its own mgmt loopback IP) the mgmt loopback interface at Site B and fail across the tunnel if it isn't reachable

[OtakarKlier]

Hello,

I use OSPF for this so its automatic and doesnt require any intervention. So setup OSPF between the sites and use Metrics to the route that you dont want as primary, ie tunnel 2. This way if either tunnel goes down, OSPF will router around the failure.

Hope that helps.

[OtakarKlier]

Hello,

Another way would be to use Policy Based Forwarding. Set it up to send traffic down tunnel 1 and have monitoring setup. Then setup a static router in the virtual router to send traffic via tunnel 2. PDF takes affect prior to routing tables in the virtual router so unless the PBF is off, due to monitoring, all traffic goes via tunnel 1 and if the PBF is off, it will route via the virtual router via tunnel 2.

Hope that helps.

[Colin_Mutch]

Hi @OtakarKlier ,

thanks for the reply.

Unfortunately due to our security policy we are only allowed to use static routing.

PBF looks promising, not something I've used before so ill need to read up on it.

[LACOUSTICS]

hello
I had the same scenario as you, but I used 2 VRs as mentioned in the link below, and it works perfectly 
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClFiCAK

But since you're using only 1 VR, I suggest using only the "tunnel monitor" in the primary tunnel and adding the route on the primary tunnel with a metric of 10 and the same routes on the secondary tunnel with a metric of 100 for example.   

[LACOUSTICS]

here is my configuration equivalent for site B in your side  

I'm using the IP on tunnel for the monitor /30

when the tunnel 1 goes down all the traffic is immediately goes through the second tunnel 

[Colin_Mutch]

Hi Lacoustics,

Thanks for the reply, your suggestion looks very promising!

On your tunnel monitoring, what source address is it using? It seems like we can only configure the dst address.

[aleksandar.astardzhiev]

Hi @Colin_Mutch ,

Am I missing something or you already have achieved what you want?

In my humble opinion you don't need dynamic routing, nor PBF.

- Create two default static routes with different metric and path monitor over each ISP. Path monitor will automatically switch over to the secondary ISP if the primary is down

- Create two IPsec tunnels to remote site with local peer IP from each ISP. Enable tunnel monitor for each tunnel. This will force the firewall to try to bring both tunnels, the second one will probably fail (it may even succeed if you use same zone for both ISPs).

- Create two static routes with different metric for remote network over the two tunnels.

When there is no problem and primary ISP is used, primary tunnel will be up and running. Tunnel monitor for primary tunnel will be up and the primary static route for the remote network will be installed in the FIB.

When primary ISP is down the static path monitor will "disable" the default route and install the secondary default  in the FIB, which should ensure that the secondary IPsec tunnel is established. Primary tunnel will go down and the tunnel monitor will "disable" primary route for remote location, so the secondary route will be installed in the FIB.

On your tunnel monitoring, what source address is it using? It seems like we can only configure the dst address.

Similar to the static route path monitor all probes are source from the address assigned to the egressing interface. In case of tunnel monitor this will be the address assigned on the tunnel interface associated with that IPsec tunnel - which means you will need to assign IP address on the tunnel interface. And more importantly this IP address must be part of the local proxy-id (if you use any). If the remote location support it, it is recommended to use 0.0.0.0/0 for local and remote proxy-id

[Colin_Mutch]

Hi @aleksandar.astardzhiev ,

thanks for the reply.

So as it's currently designed the secondary vpn tunnel is down, i dont have a way to test this tunnel without a service outage as when trying to bring it up the firewall will send ike phase 1 over the primary isp, which will be dropped at the isp router.

Since the current VPN tunnels are un-numbered, tunnel monitoring isn't possible.

I was hoping to monitor the tunnels from the mgmt loopback , so Site A 10.0.1.1 to Site B 10.0.2.1.

if it's not possible to do this and I have to add IP's to the tunnel interfaces what impact does this have internally?

Would this bring down the tunnels?

the routing table uses routes without next-hop addresses would I need to modify the routing tables at both sites?

[aleksandar.astardzhiev]

Hi @Colin_Mutch,

Assigning IP address to the tunnel interface will not have any effect on the tunnel itself, nor for the forwarded traffic. You can still use the static routes with next-hop interface, instead of next-hop IP.

Unfortunately I don't believe there is a way to use loopback IP address to be the source of the monitoring traffic. As I mentioned before, path-monitor and tunnel monitor will always use the IP address assigned to the egress interface. For the tunnel monitor, this will be the tunnel interface associated with IPsec tunnel (under which you have enabled the tunnel monitor) and for the static route it will be the interface defined under the static route.

As much as I hate PBF, if you want to test both tunnels you can create two PBF rules:

- Use remote ike peer as destination and the two local peer as source (each rule to have different source)

- Each PBF rule to use the relevant ISP next-hop.

- Enable symmetric return as well.

This should allow you to bring the two tunnels routing the traffic over each ISP.

Having that said...you may consider the option to leave the two PBF rules permanent, so the two tunnels to be always up, so the tunnel monitor or static route path-monitor for both will be always up and failover to primary will happen only when primary ISP is down.

This probably is better approach as you can monitor both tunnels status (tunnel monitor will create system log, which you setup as trap, or poll with SNMP), so you can proactively resolve issues if backup tunnel go down.

[LACOUSTICS]

Hi Colin;
Sorry for replying a late, I had some issue to deal with.
There is no need to specify the source IP address because it's the local IP of the tunnel that is used. my 2 tunnels are in a /30 subnet. 
The monitor is the keepalive between the 2 tunnels.
I don't know if it's clear xD  

[Sergi-Tost]

Hello @aleksandar.astardzhiev,

Thanks for the explanation. My question was whether it is really necessary to create the tunnel monitors in the ISP2 tunnels. I understand that when ISP1 recovers, the routes for the ISP1 tunnels will be automatically recovered, right?

Best Regards,

Sergi