Skip to main content
rosdev
rosdev
New Member
April 22, 2022
Question

NAT-T and IKEv1 rekey problems

  • April 22, 2022
  • 1 reply
  • 9137 views

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-IPsec-Tunnel/ta-p/191885?externalID=FD47032

 

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

1 reply

pminarik
Staff
pminarik
Staff
April 22, 2022

The expectations (based on some internal notes) are as follows:

  • FortiGate lets the old IKEv1 SA expire (deleted once its hard timeout is reached), before it times out it co-exists with the new IKE SA
  • The existing IPsec SA is moved under the new IKE SA (not torn down)

This raises the question of why your description of what happens in your environment is different. Can you share with us some details of the configuration and environment? Such as:

  • FortiGate model and firmware version
  • phase1 type (static, dynamic, ddns)
  • PSK or certificate-authentication
  • XAUTH used?
  • Who is the remote peer?
rosdev
rosdevAuthor
New Member
April 23, 2022

Thank you for your interest and support. As for your questions:

 

  • The Fortigate model is (VM) AWS on-demand. OS version 6.4.8 (I don't control that system so my info might be inaccurate/incomplete at the moment, but I can learn all the necessary details if needed).
  • phase1 type = dynamic
  • PSK is used
  • XAUTH is used
  • The remote peer is Libreswan (tried two different versions, this behavior is identical regardless of the peer version).

 

We took a look at this post as well:

 

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Allowing-multiple-IPSec-dial-up-connection-from/ta-p/198550

 

The symptom described there is identical to what we are experiencing and our phase2 setting is currently: "set route-overlap use-new". My guess is this setting might cause FortiGate to scrap existing SA(s) if there is an identical one (with the same routes) being established. The fact that it's a phase2 setting is slightly misleading since this is happening right after installing the IKE SA, prior to any phase2 exchanges.

 

I'll try the new setting "set route-overlap allow" on Monday. In the meantime, could you confirm or deny that this particular setting will make a difference? Or maybe there is something else to look at? I'd prefer to make an informed decision and not use the first setting that just "happens/appears to work".

Thanks,

Oleg

pminarik
Staff
pminarik
Staff
April 24, 2022

I don't think it's a good idea to do "allow" there, might cause further problems. How would the FortiGate know which tunnel to use out of the now-two? I would keep this at use-new (default).

 

I did some further digging, and I have one question for you: When the libreswan clients initiates re-key, does it send the first packet to FortiGate's port 500 or 4500?

 

Based on what I've read, we seem to expect the rekey to use port 4500, otherwise if port 500 is targeted, it is assumed to be a new negotiation (which is when the initial phase1&2 would just get torn down due to "twin connection").

 

Can you please check this and confirm?

Terms & ConditionsAccessibility statement