NAT-T and IKEv1 rekey problems

[rosdev]

Dear Users,

I can establish a tunnel to a FortiGate device correctly, but FortiGate's behavior on IKEv1 rekey events is strange. To summarize: a NAT'ed initiator establishes the tunnel to FortiGate, then after a configured period the initiator starts rekeying IKE normally. It proceeds through the 3 Main Mode exchanges. After that the new IKE SA is established as shown by this log entry:

2022-03-31 10:31:39.439141 ike 0:my-vpn2_1:646: established IKE SA edd08d7df99a2ac1/046a0210066d38c5

Immediately after that Fortigate deems the new tunnel a duplicate of a previous one, logs the "twin connections detected message" and deletes both its previous IPsec SA and IKE SA:

2022-03-31 10:31:39.439161 ike 0:my-vpn2_1:646: check peer route: if_addr4_rcvd=0, if_addr6_rcvd=0
2022-03-31 10:31:39.439187 ike 0:my-vpn2_1: twin connections detected
2022-03-31 10:31:39.439194 ike 0:my-vpn2_0: deleting
2022-03-31 10:31:39.439280 ike 0:my-vpn2_0: flushing

2022-03-31 10:31:39.441122 ike 0:my-vpn2_0:645: sent IKE msg (IPsec SA_DELETE-NOTIFY): 10.255.248.7:4500->xx.xx.xx.xx:51290, len=108, id=1d6cec7ed4ec0f25/2ff0d11d92da2d0f:c6267c37

2022-03-31 10:31:39.441252 ike 0:my-vpn2_0:645: sent IKE msg (ISAKMP SA DELETE-NOTIFY): 10.255.248.7:4500->xx.xx.xx.xx:51290, len=124, id=1d6cec7ed4ec0f25/2ff0d11d92da2d0f:21ed22e3

I don't think it's the right behavior for rekeys. It should establish the new IKE SA and let the previous one expire gracefully. It may expire on its end first or on the initiator's end first, depending on settings. In the latter case the initiator will notify Fortigate about deleting its SA and Fortigate will do the same. Tearing down the IPsec SA is an overkill, too (IKEv1 allows IPsec SA to persist without a corresponding IKE SA).

The adverse effect of this immediate SA removal is that Fortigate informs the initiator about it, the initiator deletes its SAs (the tunnel is effectively torn down as there is no IPsec SA anymore). The initiator also notifies notifies Fortigate that it has deleted its previous IKE SA. Fortigate just picks its newly created SA and tears it down. So there are no SAs for a period of time, and its the initiator that reinitializes the process from scratch.

Does anyone know how to prevent this from happening? I read this information about NAT traversal and twin connections:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-NAT-traversal-and-twin-connections-in-IPse...

NAT-T is enabled on both ends though and the initiator does switch to ports 4500:4500 during the third IKE (ID) exchange when the tunnel is set up. The parties proceed using ports 4500 afterwards. The initiator switches to port 500 only when it initiates the IKE rekey sequence (i.e. the new Main Mode exchange, again, switching to 4500 at the third exchange).

Thanks,

Oleg

[rosdev]

With regards to traffic selectors, these are clearly defined for IKEv2: the initiator has a local subnet and requests that the traffic flow between this local subnet and a remote subnet behind the peer. This is what it proposes and the responder is free to narrow down the requested subnets.

A similar declaration is made by the initiator in IKEv1, I think, during the phase 2 exchange (without the narrowing-down bit). 

What about IKEv1/phase1? What route does FortiGate add (and check for duplicates) during phase 1 negotiation? What if I disable "add-route" for phase 1 and leave it enabled for phase 2?

[pminarik]

As far as I am aware, routes are added only after phase2 is established. This consists of routes for relevant traffic (from selectors if add-route=enable), route to dialup peer's assigned IP address (e.g. from mode-cfg), or peer's IP if exchange-interface-ip=enable.