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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

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

L0 Member

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.

1 REPLY 1

Cyber Elite
Cyber Elite

@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

  • 1172 Views
  • 1 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!