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

[ergotherego]

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.

[Toshi_Esumi]

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.

[jackjohn]

Thank you for info.

Im having the same issue.

We are trying to have 2 dial VPN tunnel in 1 Branch, conecting to HQ with 2 ISP.

The idea is to have redundant if 1 ISP in HQ down.

Like you, both tunnel go up and down every 2 seconds.

We set disable route as you suggest, now both tunnel up.

Now Im working to add route, maybe I try OSPF over two tunnel.

thank you

[ergotherego]

jackjohn,

You will need to run a routing protocol for sure. You can't add static routes pointing to a dial-up IPSec tunnel, and if you disable add-route, the only mechanism left for routing is to use a dynamic routing protocol.

[jackjohn]

I just setup simple RIP as routing protocol. 

I find new issue, not related to IPsec.

in my HQ routing monitor, the prefered path is using tunnel1.

in Branch routing monitor, the prefered path is using tunnel2.

This way , my traffic cannot go thru unless I set RIP to listen on 1 tunnel only.

My guess is assymetric routing issue.

Is this expected in RIP ?

[emnoc · Accepted solution]

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]

[jackjohn]

Seting offset done.

Still ,metric in "get router info rip database" not change.

I tweak direction in/out , set status enable/disable, still no luck.

I try to apply the same RIP/offset setting to other branch that using IP sec directly ( not dial up).

It is working fine. the metric did change to new value.

So its the IP sec dial up interface that should be the issue.

I found that interface dialup IP sec has VPN_Tunnel_0 extension in naming.

This might be the issue,as I apply offset list to VPN_tunnel interface.

But strange this is, RIP is able to distribute route using interface VPN_tunnel from the beginning, as I can see the route. Only problem is the prefered path is different in HQ Fortigate and Branch Fortigate.

If Im using only one VPN_Tunnel, there is no issue.

How can it not be able to do so in offset list , or do I need to look somewhere else ?

[jackjohn]

I got it working.

My workaround  is to setup offset list in the Branch Fortigate instead in HQ.

This can be done ,since the VPN name in branch is named VPN_tunnel , without _0 in the end like in the HQ.

And I guess its accepted by offset list setting.

When I hit : get router info rip database , it finally working. Metric shows the new value.

Now my 2 tunnel is working as failover, using Dial up IPSEC.

I also had chance to experiment using OSPF, but OSPF completely would not distribute route via VPN_tunnel_0 ,that even routing will not propagate.

I dont know why is that, but RIP is the  solution for me. Somehow surprised by that.

Thank you.

[helpdesk_moc]

if we has disabled set add-route on Dynamic Peer/DialUP phase1-interface, is it not possible to add static route manually to each branch?

[helpdesk_moc]

Dear jackjohn,

How many do you have our spokes when the issues appears?