Multiple dynamic / dial-up IPSec VPN peers not working - tunnels up and down constantly

Question

Ran into this issue today and figured I would post the solution, since I couldn't find it.

Situation is a VPN hub/concentrator running 5.2.8 with multiple IPSec VPN peers configured as dynamic/dialup peers. When testing the new firewalls one at a time before shipping out, each one worked fine. But after users received them at their site, none worked. They all kept bouncing up and down. Tunnels would establish, and then with 2-3 seconds go back down again, over and over.

The solution was to disable add-route under the Phase 1 settings for each VPN peer:

config vpn ipsec phase1-interface edit "DVPN-PEER-1" set add-route disable next end

I didn't capture the log message, but what was seen was a message indicating that route 0.0.0.0/0 was being passed from one VPN to the other. Since Phase 2 selectors are set to all zeroes, and add-route is enabled by default for a dynamic peer, the hub firewall was adding a static route for 0.0.0.0/0 each time a VPN came up.

It didn't affect any other VPN tunnels or traffic, just the dynamic peers; guessing due to route cache.

Ps. I also didn't see that message about shifting routes until I configured a VPN debug filter using the known destination address of a VPN peer. With just ike debugging set to -1 I never saw that message.

emnoc · Accepted Answer

Just offset the rip hops on one link to ensure traffic is preferred over the other. Just use one side to offset in or out for the offset and that will increase the metric for the networks that matches.

Take a look at the following for a example.

[link]https://forum.fortinet.com/tm.aspx?m=131494[/link]

Toshi_Esumi · Answer

I don't know it's in RFC or not but FG has been working that way with aggressive mode IPSec and IKEv2 dynamic. If you're separating phase1-interfaces per peer, not accommodating all peers with one phase1-interface with peer IP pool like for dialup clients, you need to specify unique selectors (subnet pairs between source and destination) per peer. And those remote subnets are injected into the routing-table as static routes on the HUB side so that you don't have to configure static routes manually.

When we've learned this years ago, it probably didn't have the add-route disable option you discovered so we've never tried the same 0/0<->0/0 default selector for those and run a routing protocol over the tunnel.

Thank you for the info I want to test this myself further.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded