Dual VPN failover confusion...

[VK9H13]

Hello everyone,

Can someone offer some clarity on my questions regarding these two Palo Alto kbs?

1. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000POO0CAO&lang=en_US

In the screen shot, both primary and secondary tunnels are UP. Based on what this kb is built off of (https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PLL8CAO) aren't both of these tunnels UP ONLY through the primary ISP, due to the default route through ISP 1 being preferred and everything being in the same VR? IE we have two tunnels configured, but a default route over ISP1 preferred. All traffic will flow through that, including the second IPSEC tunnel. Am I correct?

In the event of a fail over (Either using tunnel monitoring, or Static route monitoring), failover will take longer, since phase1 and phase2 now need to renegotiate via ISP 2, and the new default route. IE failover takes longer due to tunnel 2 riding ISP1, now needs to ride ISP2 due to new default route out ISP2. am I correct? We can never have both tunnels UP riding their respective ISPs due to same VRs and a single default route.

2. I see this KB referenced a lot for the same scenario (https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClFiCAK)

I understand what is happening here. My question here is, why do we have both tunnel interfaces in VR2?

Could we not just have tunnel 1 be in VR 1, and have a PBF rule that says send all traffic out to VR1 and keep the monitor for failover? And have dynamic routing both ipsec tunnels, and if using bgp, AS path prepend on the secondary for return traffic?

In normal operations all traffic goes to VR1 (PBF), VR1 has a default route to ISP for internet, but has either dynamic routes or static routes over tunnel 1 for remote networks. If ISP 1 fails, PBF is removed. Normal routing now occurs in VR2.

Am I correct or am I wrong?

I hope this makes sense.

I am desperate to confirm whether my thinking is true or not, I do not have access to a lab quite yet where I can replicate this and see for myself.

[reaper]

yes, i also apply your thinking in my dual-is situations where i need to have redundant a/a VPN tunnels

2 VR for 2 ISP and 2 tunnels, pbf (or even static routes with path monitor) to control which traffic uses which tunnel

that way both tunnels are up and fully functional, if an ISP fails that tunnel goes down and everything reverts to the remaining tunnel (that doesn't need to renegotiate)

imho that makes most sense

[Raido_Rattameister]

With dual internet connection best solution is to set up 2 redundant VPN tunnels to 2 different IPs on remote side and set static routes to those IPSec peer IPs over different links. In general "Strict Source Path" is meant to avoid setting static routes but unfortunately if one ISP is down then Strict Source Path setting don't block IPSec connection attempt from being sent over remaining ISP link.

By setting up 1 virtual router per ISP you loose possibility to load balance outgoing traffic as from third "internal" virtual router you can't set equal path to 2 different virtual routers as next hop.

PBF is no help either because PBF does not apply to traffic sourced from Palo itself. It can only route traffic passing through the Palo. So you can't use PBF to choose which path IPSec traffic takes.

[VK9H13]

Thank you for the response. This is really helpful and makes me feel not crazy. The first kb link seems to ignore the fact that vpn2 will be negotiating through isp 1 if using default routes.

in the second kb, utilizing 2 virtual routers, can you explain why tunnel 1 and tunnel 2 are in the same vr rather than having tunnel 1 and isp 1 in the same vr? Imo you can just do this, and it will work the same if you use pbf to send all traffic to vr 1 with a monitor, rather than sending only internet traffic to vr1 as described in the kb. Not that there is anything functionally wrong with the kb, I’m just curious of the benefits having the tunnel 1 and isp 1 separated. 

[VK9H13]

My problem with /32 routes to peers is it doesn’t seem that scalable if you’ve got a ton of tunnels. I understand your reasoning though. 
thinking of all possible scenarios, couldn’t we theoretically have bgp running between the virtual routers, when utilizing virtual routers, and have the virtual routers peer via bgp and utilize ecmp there for load balancing?

[Raido_Rattameister]

If you can run tunnel on BGP IP that can be advertised/reached over both ISPs then 1 tunnel is enough.

If one ISP fails then tunnel will use other ISP and same WAN IP.

[OtakarKlier]

Hello,

I do this in scenario A where I have multiple tunnels between two devices. However I use OSPF with metrics to send the traffic down one tunnel and failover to the other etc. I dont need 2 VR's in my case.

Basically I let OSPF do the fail over routing since one tunnel will be down and dropped from the routing table.

Regards,

[VK9H13]

Do you use multiple isps? And if so, when building multiple tunnels, do you use /32 routes for the peers or use default route?

[OtakarKlier]

Hello,

I would use /32 addresses. This way you control which interface/direction the traffic is flowing.

Regards,

[Dream11PaloAltoFW]

Hi,

Could someone assist with my ongoing operational concern? I've set up two IPsec tunnels with AWS via ISP1 and ISP2, utilizing BGP routing. Both tunnels are active and functional on both Palo Alto and AWS ends. However, when I deactivate ISP1, traffic fails to transition to ISP2, and in the BGP Local RIB, only details for the two tunnels of ISP1 are displayed, rather than all four expected. Additionally, I've adjusted the import rule to prioritize ISP2 with a value of 100 in the local preference tab without success.