How to Configure a Palo Alto Networks Firewall with Dual ISPs and Automatic VPN Failover

by panagent on ‎01-24-2013 10:38 AM (166,609 Views)


This document explains how to configure a Palo Alto Networks firewall that has a dual ISP connection in combination with VPN tunnels.

Configuration Goals:

  • A single device with two internet connections (High Availability)
  • Static site-to-site VPN
  • Automatic failover for Internet connectivity and VPN


This setup is frequently used to provide connectivity between a branch office and a headquarters.  ISP1 is used as the primary ISP on Ethernet1/3.  ISP2 is the backup ISP on Ethernet1/4.


The configuration is identical on both firewalls, so only one firewall configuration is discussed. In this example, there are two virtual routers (VR).

Dual Diagram.png

Interface Configuration

Configure two interfaces:

  • Eth 1/3: (connection to ISP1) in the untrust zone
  • Eth 1/4:  (connection to ISP2) in the untrust zone

Virtual Routers

There are two virtual routers:

  • VR1: Primary (ISP1) (Ethernet1/3)
  • VR2: Secondary (ISP2) (Ethernet1/4)

Each VR has an ISP Interface attached, but all other interfaces will stay connected to VR Secondary, as well as all future interfaces. The purpose is to let all interfaces be known by connected routes and routes on the VR as their routing method when the Main ISP goes down.

  • Primary VR has Ethernet1/3 interface attached

Primary Router GEn.PNG

  • The Primary VR routes include the default route and return routes for all private addresses back to the Secondary VR, where the actual interfaces are as connected routes. When the traffic is forced out the interface through the PBF, the traffic will know how to get back to the Secondary VR where the interfaces live.

Primary Routes.PNG

  • Secondary VR has the Ethernet1/4 attached with all the other interfaces, as shown below:

Secondary Router GEN.PNG

  • Secondary VR routes for all connected interface will show up on the routing table as connected routes, and the route for the tunnel will be taken care of by Policy-Based Forwarded (PBF).
  • To force the traffic out the Primary ISP interface, use the PBF Sourcing from the Trusted Zone:

PBF Source.PNG

  • The firewall tells the PBF not to forward traffic destined to a private network, since it cannot route private addresses on the Internet (as there might be private network addresses that need to be forwarded out). Click Negate.


  • As shown in the example below, set up the forwarding out of the Primary Interface, with monitoring to disable the rule, if the destination being monitored is not available. Revert the traffic to use the routing table of the Secondary VR where all connected routes exist.

Forward Tab complete.PNG

  • Configure a Source NAT policy for both ISPs. Make sure to define the destination interface on the "Original Packet" tab for both Source NAT rules.

Screen Shot 2015-02-05 at 4.52.14 PM.png

The reason for the multiple VRs is because both tunnels are up and running at the same time. If connectivity is to ISP1, it will failover to ISP2 as soon as possible. If the backup VPN over ISP2 is already negotiated, that will speed up the failover process.

Phase 1 Configuration


For each VPN tunnel, configure an IKE gateway.

Phase 2 Configuration


For each VPN tunnel, configure an IPSec tunnel. On the IPSec tunnel, enable monitoring with action failover if configuring the tunnels to connect to anther Palo Alto Networks firewall. Otherwise, set up the PBF with monitoring and a route for the secondary tunnel.

Tunnel Monitoring (Palo Alto Networks firewall connection to another Palo Alto Networks firewall)

  • Primary tunnel with monitoring.

Primary Tunnel Monitor .PNG

  • Secondary tunnel with monitoring.

Secondary Tunnel Monitor.PNG

  • In Action, configure the Monitor Profile to Fail Over.

Tunnel Monitor.PNG

  • With this method, using tunnel monitoring there are two routes in the routing table, the first with metric of 10 for the Primary VPN traffic, and the second with the metric of 20 for the Secondary VPN. Since the tunnels terminate on the Secondary VR, the routes will be placed on that VR.

Routes for VPNs.PNG

Policy-Based Forwarding (Palo Alto Networks firewall connection to a different firewall vendor)

  • This method can be used when the connection is between two firewalls.
  • State from what Source Zone.


  • Indicate when the traffic is destined to the network on the other side of the tunnel (in this case it is 192168.10.0/24).

Destination PBF.PNG

  • Forward the traffic down the tunnel.

Forward PBF.PNG

  • When the PBF is disabled, because the destination is not reachable, the other VPN will start using the routing table with a route that has the same destination but is using the other configured tunnel.

Note: In the above example, a probe is sent out to to check if it's reachable. The probe must have a source IP address and will use the IP of the egress interface, which will be the IP address of the interface 'tunnel.' If an IP address is not configured on the tunnel interface, the PBF rule will never be enabled. In this scenario, an arbitrary IP needs to be configured, such as A static route for destination must be added with next-hop as the tunnel interface. Otherwise PBF will always fail because traffic initiated from the firewall will not hit the PBF rule. Make sure the remote device knows how to return the packet. When working with a Cisco ASA, make sure it knows how to return traffic to Additionally, configure a Proxy ID for this network on the Palo Alto Networks device's IPSec tunnel configuration.

owner: rvanderveken

by skrall
on ‎10-08-2013 02:42 PM

When testing connectivity, do not use any IP address owned by the firewall as one of the endpoints. Addresses owned by the firewall can not POLICY BASED FORWARDED.

by mario11584
on ‎01-28-2014 03:53 PM

"For each VPN tunnel, configure 2 PBF entries"

Looks like only one per tunnel was configured. Does the writer mean 2 PBF entries on each side of the VPN?

by santonic
on ‎12-09-2014 04:38 AM

What happened to the previous version of document? Is that one still ok to use? I find solution with 3 VRs more logical.

And shouldn't one of the tunnel interfaces be in Primary VR in this example?  Because one of the tunnels is terminated on IP address of Primary VR

by glasater
on ‎12-09-2014 04:47 AM

Use of three VRs is easily scaled from two with the same concepts that are with two. The use 3 VRs initially is excessive and unnecessary for a basic dual ISP with VPN failover. The example here is more logical to configure for most designs.

by santonic
on ‎12-09-2014 05:35 AM

What about tunnel interfaces? Shouldn't each tunnel interface be in the VR where the VPN is terminated? So one of the tunnel interfaces should be in Primary VR?

by glasater
on ‎12-09-2014 05:50 AM

No, All interfaces would terminate on the secondary VR. This makes it so that there is minimal configuration of routes needed. the Gateways can be created on the Untrust interfaces respectively, but the Actual Tunnel terminate on the Secondary VR with all other LAN, Tunnel and other interfaces and the firewall will already know where the connected routes are on that VR for the Traffic coming out of the tunnel, so hence no need for unnecessarily routes configured. The only routes in the Primary VR being return routes for private address as needed for traffic pushed out that interface.

by santonic
on ‎12-09-2014 05:59 AM

Ok, thank you for info.

Gonna configure it tomorrow and see how it goes.

by glasater
on ‎12-09-2014 06:02 AM

Yes. No problem. This what PA engineer here in our office use for configuration and is recommended. in cases where you might get or add a third ISP you can expand on this configuration easily. But for the majority of configurations there are only 2 ISPs. and the main reason this is recommended is for each VR to have the respective route for traffic generated from the box to use to make sure we keep traffic symmetric.

by santonic
on ‎12-09-2014 06:32 AM

I will have to expand it a bit as well. FW on the other side (not PA) also has 2 ISPs so I'll have to make 4 tunnels to cover all scenarios.

by glasater
on ‎12-09-2014 06:37 AM

Since you are going to a Non-PA firewall tunnel monitoring has some additional requirements mentioned in the the following Doc:

Selecting an IP Address to use for PBF or Tunnel Monitoring

Also, a more detailed explanation on DPD and Tunnel Monitoring Doc is below here:

Dead Peer Detection and Tunnel Monitoring

These should help as well. On a side note, when thinking about traffic passing through the PA or sourced from it. PBF policy is only for Traffic traversing the Palo Alto. Traffic sourced from the Palo Alto will always use the routing table. Another reason for Separating ISP interfaces to their own VR in general. Especially for things like VPN gateway route to peers.

by santonic
on ‎12-10-2014 03:36 AM

Thanx for additional info.

Yeah, i know about restrictions with PBF and traffic originating from the device itself.

by traymondchia
on ‎03-26-2015 02:48 PM

Interesting document.

the only more or less important missing piece I can think of here is related to security policies for the scenario.

by santonic
on ‎03-30-2015 12:16 AM

Security policy is the same whether you have VPN redundancy or not. Only traffic routing is different.

I would also like to thank again for this document. It was helpful with my scenario as well: PA central location with non-PA remote locations, dual ISPs on central and remote locations, dynamic IPs with one of the providers on remote locations.

However sometimes comes a situation where both devices have IPSEC up, routing is correct, both devices are using same SPI-s and traffic still isn't going through VPN tunnel. Weird stuff.

by mkhavari
on ‎04-10-2015 08:37 PM

Thank you for this document. I followed your instructions on setting up the VRs, however when I fail to the secondary ISP, I was unable to ping an external host on the internet. I removed the static called "Primary ISP" from the Primary VR and added a static route on the secondary VR point to the secondary ISP and I was able to failover and failback between the two ISPs. Would this configuration work while following this document to complete the configuration?

by Thibaut_Vilminot
on ‎05-27-2015 09:43 AM


Thanks indeed for this document.

However, I am not sure to see the point of the 2 VR, as most of the configuration is done on the Secondary VR.

Wouldn't it also work with only 1 VR?

by pulukas
on ‎05-27-2015 03:03 PM

There are two VR because we need to have two default routes, one for each ISP.  A single router can only have the one active default route.  By separating each ISP into their own router we can keep both links active and the routing tables complete.

by Thibaut_Vilminot
on ‎05-28-2015 07:34 AM

Hi Steven,

Thanks for your quick answer. However, why put 2 default routes, if the route to ISP1 will be handled by the PBF? I mist miss something.

by mario11584
on ‎05-28-2015 08:53 AM

Traffic sourcing from the firewall won't use PBF rules. You'll want static routes for both ISPs for traffic that sources from the firewall.

by Thibaut_Vilminot
on ‎05-28-2015 08:58 AM

Indeed, forgot about that! Thanks for the explanations!

by LeandroBarbosa
on ‎06-06-2015 07:39 AM


I have problem with vrouter routing.

the following scenario:

I have two PA-200 at headquarters and branch, the headquarters has two wans and branch as well.

in the headquarters:

1/1 - wan Embratel

1/2 - wan Oi

1/3 - LAN

vrouter-Embratel with default gw

(Route tunnel.8 metric gw 10)

vrouter with Oi-default gw

(Route tunnel.9 metric gw 10)

tunnel.8 with vrouter-Embratel monitor ip

tunnel.9 with vrouter OI-monitor ip


(Route gw next-vr vrouter-Embratel metric 10)

(Route gw next-vr vrouter Oi-metric 20)


source zone: LAN


action: foward

Egress Interface: tunnel.8

profile: failover

next hop:

Monitor IP:

disable this rule .....

source zone: LAN


action: foward

Egress Interface: tunnel.9

profile: failover

next hop:

Monitor IP:

disable this rule .....


LAN - VPN full acess

VPN - LAN full acess

in the branch:

1/1 - wan Embratel

1/2 - wan Oi

vrouter-Embratel with default gw

(Route tunnel.8 metric gw 10)

vourter with Oi-default gw

(Route tunnel.9 metric gw 10)

tunnel.8 with vrouter-Embratel monitor ip

tunnel.9 with vrouter Oi-monitor ip


(Route gw next-vr vrouter-Embratel metric 10)

(Route gw next-vr vrouter Oi-metric 20)


source zone: LAN


action: foward

Egress Interface: tunnel.8

profile: failover

next hop:

monitor ip:

disable this rule.....

source zone: LAN


action: foward

Egress Interface: tunnel.9

profile: failover

next hop:

monitor ip:

disable this rule.....


LAN - VPN full acess

VPN - LAN full acess

I'm closing with the vpn wan Embratel headquarters with Embratel branch wan affiliate, the I do the same with Oi wan.

When the affiliate Embratel link falls redundancy for the link Oi works, though the heardquarters can access all affiliate resources except for the ping ip affiliate to PA-200 LAN, check the routing headquarters that route vrourter-LAN remains active by tunnel.8, in the case could not because the vpn fell.

vrouter-lan (headquarters) display by "show routing route" in CLI gw next-vr vrouter-Embratel 10 (A) gw next-vr vrouter-Oi 20

Why does it happen this issue in the Firewall kernel routing?

other resources does not fall by the network due to OI PBR which is active.

by Rene
‎11-13-2015 07:30 AM - edited ‎11-13-2015 07:35 AM

What are those Monitor IP addresses for the tunnel monitoring (Palo Alto to Palo Alto connection)?

I see IP addresses and configured as Destination IP.


Are these arbitraty IP addresses setup on the tunnel interfaces to be monitored?

As I think these cannot be an IP address on the remote subnet as they are both in a different subnet(?)


And what about the configuratoin on the other end when it only has 1 internet line?

Do you need to create 2 IPSec tunnels on 2 different tunnel interfaces and setup 2 routes for the return traffic toward the 2 different tunnel interfaces, one with metric 10 and the other metric 20? 

by mali77
on ‎03-13-2017 07:47 AM

I have a similar situation but in my case both ISP's are connected to the same VR.  Can I accomplish the same if both are connectec to the same VR?

on ‎03-13-2017 08:11 AM

It can be accomplished but will grant you less flexibility. If you simply want to differentiate between outgoing traffic (eg bandwidth consuming browsing and mission critical applications), this will work just fine

by mali77
on ‎03-13-2017 10:04 AM

Thank you for the reply, is there any documentation for that by any chance?


Basically I have



ISP1 (eth1/7)

--------------> WAN-VR2

ISP2 (eth1/8)


Then I have a whole bunch of other sub interfaces on the LAN side:


trust1 eth1/24.1

trust2 eth1/24.2

trust3 eth1/24.3


Do I start with creating PBF under VSYS3?


Do I create a



on ‎03-13-2017 10:20 AM

The article above is the recommended setup, if you choose to only use 1 VR your options get limited to policy based forwarding

by mali77
on ‎03-13-2017 10:30 AM

I understand that however I am unable to set it up like that because of the way existing setup is.  I have a need to try to do it with both ISP's connected to the same VR.  My understanding is Palo can't just simply do multiple default routes.  And I also have the LAN side connected to a different VR so even if I create a secondary VR for the second ISP.  I will then need to move the whole LAN under the secondary VR.  Which means downtime and just can't do that right now.

by IT-Admin
on ‎03-13-2017 07:38 PM

We're looking to follow these directions. However, there's some steps that needs clarification, such as the secondary VR static routes to internal LAN. On the primary VR, it shows that the internal LAN subnets get routed to next VR (secondary VR). On the secondary VR, should we also set static routes to our next hop (to our core LAN router)?

Also, the secondary VR default route for "" goes to, shouldn't this be to the gateway of the 2nd ISP? Unsure where comes from in the example.

If the PBF is disabled, how does the internal LAN know to route through the secondary VR?

on ‎03-14-2017 03:43 AM

@IT-Admin : on your second VR the internal network would be a connected network, so no static routes are needed unless your internal network has a router. so in your case, yes you need additional static routes on VR2 for your LAN networks, pointing to the LAN router next hop


correct, that appears to be a typo, this should be 10.80.40.x


the second VR is connected to the networks, so if the PBF fails/is disabled, vr2 will be default for all traffic

by max.strzelecki
‎06-22-2017 02:58 PM - edited ‎06-23-2017 01:11 PM

@reaper, could this configuration be simplified into a single virtual router by using Path Monitoring? By making a second default route with a higher metric, and adding path monitoring to the first default route. 


I was reading the help about path monitoring, which says:

If all of the monitored destinations for the static route are unreachable by ICMP, the firewall removes the static route from the RIB and FIB and adds the dynamic or static route that has the next lowest metric going to the same destination to the FIB.


on ‎06-26-2017 02:58 AM

Hi @max.strzelecki that way the secondary tunnel will rely on the same default gateway as the primary tunnel and will fail when the primary ISP fails


the dualVR solution provides a way to build 2 stable standalone transport mechanisms and build redundant routing on top of that (rather than needing to try combine your application routing AND vpn routing in-one)

by ptrivino
on ‎06-28-2017 01:06 PM

This document could use some improvement. 


  1. The PBF rule shown is not helpful. It shows "everything NOT RFC-1918 addressed" but that's not realistic. Why not take any RFC-1918 /24 network and use that for the example? (Note that the end "tunnel to a non-PAN device" section does that.) The VPNs are going to be linking two parts of ones internal private network, so all of RFC-1918 can't exist at one end.
  2. Explain the basic idea of this setup, which is: use the secondary ISP link and secondary VPN tunnel with ROUTING, and then use PBF policy rules to OVERRIDE the routing to send traffic to the Primary ISP/tunnel.
  3. There's a small note at the end  to make sure the other end knows how to return the monitoring pings - important.
by km2264
on ‎07-17-2017 12:45 PM

Hi, This is a great article. One item I did not see covered is how to handle NAT for specific services. An Example, if you have two ISP's and are using an address off the primary ISP for incoming email with a Public DNS address for the scondary ISP, how is this accomplished with this scenario?


Primary ISP =

Secondary ISP =

Internal Mail Server on Primary ISP Natted as

Internal Mail Server on Primary ISP Natted as


Not sure how to configure the secondary NAT to forward to the Internal Mail Server and NAT out with the secondary address if the Primary ISP goes down.




by Rene
on ‎07-24-2017 01:59 AM

Hi @km2264,


Not sure what you are asking but I think it is about NAT and return traffic on the seconds internet line.

NAT works exectly the same as on the primary line but to be sure that the traffic incoming on the secondary line is returned on the correct internet line (ISP2) you need to create a PBF rule.

The PBF rule should look like this:

Source type is: Interface

Interface: select your interface of ISP2

Destination address: the DMZ IP address of your service (NAT is done before the PBF rule, that is why you use the DMZ address)

Forwarding egress interface: you DMZ interface (where the internal servers live)

Enforce Symmetruc Return should be enabled and add your secondary ISP default gateway to the Next Hop Address Lisrt. This way traffic is return via your secondary internet line.


You can add all services on you DMZ that should be reachable via the secondary internet line to that same PBF rule.

When you have another destination zone/interface for servers, you need to create a another PBF rule.


Hope this helps

by Mohamed-Hakim
‎09-04-2017 09:27 AM - edited ‎09-04-2017 01:33 PM

if user access internet from ISP1 but need only VPN traffic from ISP2 is PBF policy below correct?


  • Source Zone: trust
  • Destination Address: Peer's public IP (for example:
  • Action: forward
  • Egress I/F: tunnel interface (for example tunnel.1)



by Nick.Spender
on ‎01-27-2018 04:43 PM



Hello Reaper


Couldn't I simplify the configuration by having 1 VR and 2 default routes first one with a lower metric and path monitoring and the second with a higher metric and no path monitoring?


Then 2 tunnels, first one bound to ethernet interface primary and the second bound to ethernet interface secondary....maybe change metrics and add path monitoring if needed


Then add PBF for the primary tunnel. 


Would the above work?


Thank you in advance


by Nick.Spender
‎01-28-2018 05:54 AM - edited ‎01-28-2018 05:57 AM

Hello everyone


So I've sat down with an old fashion pen and paper. It all makes sense. I just can't figure out why tunnel 1 (primary) is set to use the secondary VR. It's bound to the primary ISP interface but is using the secondary VR.....I think I need a really dumbed down reason why. 


Also the peer side isn't a PA so I'm not using tunnel monitoring. 


Thank you :)

on ‎01-29-2018 03:05 AM

i'll paste my explanation here too (same question was asked in different article) so other people can benefit:



Each VR has an IPSec connection (let's call it this for clarity) that depends on the VR's default route to get to the remote end and establish.

The other VR does not need to be aware of this connection


The physical IPSec connection results in a virtual tunnel interface being created that can live anywhere, in this scenario the 'tunnels' live in VR2 and PBF is used to 'put traffic into' these tunnels.



Ignite 2018
Ask Questions Get Answers Join the Live Community