Two ISP, one IKE-gateway. Loopback as IKE-source, source-nat - session and IKE never actually reset.

[Olof_Lundgren]

What I am trying to achive:

I have two ISPs with two different static IPs.

I want to create one tunnel to one remote site.

Tested with panos version: 9.1.14-h4

Loopback IP: 192.168.99.1/32 inside zone

eth1/1 WAN1: 11.11.11.11 outside zone

eth1/2 WAN2: 22.22.22.22 outside zone

Tunnel IP: 172.16.99.2/30 inside zone

Both ISPs have RP-filter strict (setup in a lab)

I have one policy rule that allows everything from inside to outside zone.

I have setup two dynamic source-nat rules, based on both outside interfaces.

I can do:

ping source 192.168.99.1 host 88.88.88.88

Turn off WAN1

and ping will continue to work, and I can see in session table that it has updated its source-nat session.

This means: NAT works, on both interfaces. Policy rules work

Now, try the same thing with IKE+IPSEC.

IKE-gateway, sourced from loopback, using fqdn as local-id. Enable NAT-T on both ends.

Tunnel comes up, great success! I can see in session table that it is source-nat'ed.

Turn off WAN1.

I can see that packets leaving WAN2 now has the public IP of WAN1. Now this is ofcourse blocked by ISP routers because they have RP-filter strict. 

IKE process doesnt seem to ever be reset, and to solve this I have to do two things: clear session table, and clear ike-sa. (in that order)

Now finally IKE can reach remote gateway.

My issue is, even though I played around with Liveness Check timers, and monitor-profile failover/recover, the IKE-process doesnt seem to be restarted (it uses same source UDP port when trying to create IKE Initiatior request). This leads to NAT not being able to update its sessions, and not using a new outgoing IP on WAN2.

I dont know what ipsec implementation is under the hood, but if a liveness check reset where to happen - AND IKE process would use a new outgoing UDP source port per ike-gateway (when NAT-T is enabled), this would probably work as expected.

[BPry]

@Olof_Lundgren,

So the procedure for this is actually that you'll have two tunnels configured. If you don't want to do that, you'll need to script something to manually reset the tunnel in the event of a failure to get it to behave like you want. While I'm a big fan of scripting and the XML-API, I'd really recommend you go with the two tunnel method since it's a faster failover. 

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000POO0CAO