Multiple VPN (ipsec) To Same Destination

[kanes39]

Hi Team,

I have configured 2 IPSEC to the same remote destination and it was working fine with version 6.4 however after the upgrade it stopped working. The reason for that is that the Tunnel ID for the second tunnel is assigned with an IP of 10.0.0.1 and not the public IP (which is assigned to the first IPSEC). Apparently, there is a behavior change on version 7.2. (In general, tunnel IDs are assigned the IP address of the remote gateway. If multiple tunnels use the same gateway IP address, then a random IP address from the subnet 10.0.0.0/8 is assigned).

Has anyone encountered a similar issue and what is the recommended fix?

Appreciate your help and assistance.

[paulistic]

I've had issues after upgrading to 6.4 - but I suspect that was because the return traffic would go through the other tunnel - resulting in RPF fail. Check the exact path of the packets on the far end.

[sw2090]

hm it works here in 6.4.9 with 0.0.0.0/0.0.0.0 as p2 selector and prio/distance based routing and policies.

So traffic pimarily hits the tunnel with the lowest routing prio/distance and if that were down it would hit the next one.

[kanes39]

Hi Gents,

Thanks for the reply.

This was absolutely fine with version 6.4 but now on 7.2 this is an issue.

The 2nd tunnel to the same peer is getting assigned a 10.0.0.1 tunnel ID and that is getting translated into the routing table and when tunnel 2 becomes active traffic GOES nowhere. If I cannot find a solution might need to downgrade the firewall. Got it working now by reducing the AD of the 2nd VPN tunnel route and forced it to the first tunnel. 

[pminarik]

In 7.0.1+ there was a change which binds IPsec-tunnel routes to a "tunnel ID". It looks like an IP, but from my current understanding it actually isn't.
Here's a page documenting the change in behaviour - https://docs.fortinet.com/document/fortigate/7.0.0/new-features/649094/dedicated-tunnel-id-for-ipsec...

If you believe that this is messing with your routing, please strongly consider opening a case with the TAC to review the situation. (before you downgrade, so that they can gather any necessary debugs)

[kanes39]

Thank you @pminarik. This is definitely causing the mess in our design.

I have raised a TAC case with Fortinet and the engineer has suggested the following:

a) Redesign the network and not use the 0.0.0.0 IP.

b) Downgrade the FW.

There seems to be no other option. I did read the documentation and is there anything else we can do to get this working. We have about 10 sites which are using the exact same design. Any other way of getting this fixed?

Appreciate all helps - thanks.

[akristof]

Hi,

Which FOS version you are on, exactly? Usually, having overlay-ip configured on tunnel will help. But what exactly is the problem? The tunnel-id is used to find correct tunnel, usually with net-device disabled as this setting replaced tunnel-search option. The traffic is entering incorrect tunnel?

[kanes39]

Hi @akristof - FOS 7.2

[pminarik]

I would agree with @akristof and suggest to try setting IPs for the tunnel endpoints. These are point-to-point links, so any four random /32 should suffice.

[kanes39]

Thank you gents.
I will try with the random IP address and we will see if it works and possibly test it with the second VPN and see if that solves the issue.