IPSec VPN routing across multiple tunnels

[darren_g]

Hi folks/.

I have a situaiton that is doing my head in, and I need some help.

I have an installation which looks like this

"A" end - Palo Alto Active/Passive cluster, public IP for IPSec VPN termination

"B" End - Juniper SRX cluster, Active/Active with TWO IP addresses (separate links) for IPSec VPN initiation

I have configured two tunnels from the SRX to the Palo Alto - different tunnel interfaces, different IPsec tunnel and IKe configurations - and they come up just fine (after some fine tuning).

Where I'm running into trouble is getting routing to work.

I've added a static route for the remote subnet into the virtual router pointing to the main tunnel, and a second one pointing to the secondary tunnel with a higher metric (administratifve distance), but for some reason if the primary tunnel drops (there are issues with re-keying I'm working on with the Juniper side), the routing does not switch to the secondary.

Can I configure the routing on the Palo Alto so that it checks for the other end - even if the tunnel is up - and fails to the second route if it gets no reply across the primary tunnel?

I am scratching my head here - for the life of me, I can't make these things match up on both ends - so I'm looking for help on the Palo Alto end here to see what I can do to try and improve things.

Thanks for anything you guys can point to.

[BPry]

@darren_g,

Do you have a tunnel monitoring profile assigned to the tunnel at all? 

[darren_g]

---

@BPry wrote:

@darren_g,

Do you have a tunnel monitoring profile assigned to the tunnel at all? 

---

@BPryNo, I don't, because I don't really understand the purpose and functionality of them - they seem pretty simple to configure, but how do you apply them - and more importantly, how do you tell them which tunnel to fail over to?

[BPry · Accepted solution]

@darren_g,

The purpose is pretty much what you are asking for here. Tunnel Monitoring will ping the destination and make sure that it gets a valid response back and that traffic is actually processing properly. Where DPD checks that the IKE-SA is still valid, tunnel monitoring can verify that something on the other side of the tunnel is actually still reachable.

You'll have two different options here.

• Wait Recover
• Fail Over

Wait Recover is essentially only their to acclerate the negotiation of new IPSec keys, other than that it doesn't do anything but log the event.

Fail Over on the other hand will actively disable the tunnel interface and disable the associated routes in the routing table. This would force the traffic to your second tunnel.

[darren_g]

@BPry 

That's good, but how do you tell it which tunnel to fail over to?

I can't see where to configure it to pick a specific tunnel to fail the traffic over to. Do you simply set two static routes pointing to both tunnels, or is there some other magic that needs to be worked to make this selection choice?

Thanks

[BPry]

@darren_g,

You don't tell it which tunnel to fail over to, it simply disables the tunnel interface. Disabling the tunnel interface will take your first route out of consideration as far as the firewall is concerned (because it can't use a disabled interface) and the second route you have configured will take over as it's the remaining route. 

Another option of doing essentialy the same thing is configuring Path Monitoring on the route entry itself, which would be independent of the Tunnel Monitoring. You can view that method of operation HERE

Essentially either option would work fine here, but the Tunnel Monitoring helps you by attempting to re-negotiate the IPSec keys between peers instead of simply removing the static route. 

[darren_g]

---

@BPry wrote:

@darren_g,

You don't tell it which tunnel to fail over to, it simply disables the tunnel interface. Disabling the tunnel interface will take your first route out of consideration as far as the firewall is concerned (because it can't use a disabled interface) and the second route you have configured will take over as it's the remaining route. 

Another option of doing essentialy the same thing is configuring Path Monitoring on the route entry itself, which would be independent of the Tunnel Monitoring. You can view that method of operation HERE

Essentially either option would work fine here, but the Tunnel Monitoring helps you by attempting to re-negotiate the IPSec keys between peers instead of simply removing the static route. 

---

Ahh, OK, so I just enter two static routes to the different tunnels, and if the primary fails, it disables and the other route automatically takes over. That's a lot clearer now. Thanks!

So when you apply the tunnel monitor, the "destination IP" is any address on the other end of the link? Or is it specifically the tunnel interface address at the other end?

I'll look into path monitoring too - thanks!

[OtakarKlier]

Hello,

Policy Based Frowarding with monitoring is another method you can use.

Regards,

[CarlosFernandez123]

@BPtry, 

when you say "Fail Over on the other hand will actively disable the tunnel interface and disable the associated routes in the routing table" are you saying if I have a static route pointing to a tunnel interface and the tunnel fails, the tunnel monitoring process will remove the static route pointing to that tunnel interface?