Two IPSEC Tunnels to the same Remote Gateway

[KrisK]

Some of my FortiGate devices are showing two IPSEC tunnels to the same remote-gateway.

The tunnels show up with the names NAME_0 and NAME_1.

This causes ping to fail because ICMP will come in through NAME_0 and then the ICMP response is dropped due to Reverse Path Fail.

Is there a way to prevent the two IPSEC tunnels NAME_0 and NAME_1 from being created?

The routing table indicates that the default route (learned via BGP) goes through NAME_1. This seems to be the cause of the RPF packet drop.

[akristof]

Hello,

Thank you for your question. Is this ADVPN setup? Or just site to site tunnels? We will need more details on the setup, if you can show us config of tunnels it would help to understand your setup.

[KrisK]

Thanks for the reply Adrian. This is an ADVPN setup, but I am still trying to understand the tunnel configuration. If I use 'diag vpn ike gateway clear name NAME_1', then the pings start working. I can also see the routing table and the ipsec tunnel list back in sync so that RPF isn't an issue anymore.

I'll be able to describe the tunnel configs after more investigation.

[akristof]

Hi,

In general, make sure that you have these settings:

net-device enable on spoke, disable on HUB

tunnel-search next-hop on spokes (if you are on 6.4 and lower)

add-route disable

And with BGP, you should have ibgp-multipath with additional-path configured.

[KrisK]

Looks good:

- net-device enable on spoke, disable on HUB

- add-route disable

Potential Issue:

- tunnel-search next-hop on spokes (if you are on 6.4 and lower) << 'set tunnel-search nexthop' is on the hub, not the spoke (firmware is 6.4.5).

- ibgp-multipath with additional-path configured. << Does not appear to be configured. Will research this.

Thank you.

[sw2090]

this sounds like the typical behaviour of dial up vpn on a FGT. This is called "concurrent connections". You just need to take care that the name of your Phase1 is not too long because the FGT needs some space for the enumeration of the connections (<p1name>_number).

You do not need to care about the enumartion in static routes and policies. You just set a static route to the vpn subnet to the phase1 name and define policies for the traffic same way.

If the FGT states "reverse path check failed" or similar ithat just means you don't have any static route back to your vpn clients at all. However I'd say since tunnels are like interfaces it should have a connected route to the client. 

You could check the routing table on your FGT. Do you use mode_confg and/or split tunneling in that vpn?

[KrisK]

Thank you for the reply.

Great advice about keeping the name short. Thankfully, this is not an issue.

I'm not using dial up VPN and I don't see any good reason why I would want concurrent connections or split tunneling. It seems I have an unintended configuration setup.

I think a static route may solve this issue. However, this is a case where most of the network seems to be fine and only a few devices have an issue that comes and goes. Therefore, I don't want to mess up my topology by hacking away at it. I will keep looking at how and where to implement the static route.

I'm not familiar with mode_confg, so I'll have to look this up.

More to follow.