Troubleshooting Tip: IPsec VPN connection fails with error 'twin connection detected'
Description
This article describes a known behavior in which FortiGate devices fail to process the IKE_AUTH response during IKEv2 negotiation, resulting in VPN connection failures with the error 'twin connection detected'.
Scope
FortiOS.
Solution
Under normal operation, the IKE process listens on the reserved UDP ports 500 and 4500, as shown below:Â
FortiGate# diagnose sys udpsock | grep 500Â
0.0.0.0:4500->0.0.0.0:0 state= txq=0 rxq=0 uid=0 inode=36896 process=200/iked Â
0.0.0.0:500->0.0.0.0:0 state= txq=0 rxq=0 uid=0 inode=36895 process=200/ikedÂ
In certain cases, FortiOS may mistakenly bind UDP port 4500 to the cw_acd process. As a result, the IKE daemon does not receive the IKE_AUTH response and the IKEv2 negotiation fails.Â
FortiGate# diagnose sys udpsock | grep 4500
0.0.0.0:4500->0.0.0.0:0 state= txq=0 rxq=379456 uid=0 inode=34290 process=225/cw_acdÂ
The following is an example of the flow for a failed VPN negotiation:Â
VPN Peer1 (initiator):
Peer1_INET:791: sent IKE msg (SA_INIT):Â
1.1.1.1:500-> 2.2.2.2:500Â
comes 2.2.2.2:500->1.1.1.1:500.Â
IKEv2 exchange=SA_INIT_RESPONSEÂ
IKE msg (AUTH): 1.1.1.1:4500-> 2.2.2.2:4500 <--------- Sent IKE_Auth message Â
VPN Peer2 (Responder):Â Â
sent IKE msg (AUTH_RESPONSE): 2.2.2.2:4500->1.1.1.1:4500 <---- Sent IKE_Auth_Response messageÂ
Due to the cw_acd listening on UDP/4500, the initiator FortiGate never processes the IKE AUTH_RESPONSE, and the responder FortiGate instead retransmits IKE_AUTH until negotiation timeout occurs. Â
Peer1_INET:791: sent IKE msg (RETRANSMIT_AUTH): 1.1.1.1:4500->2.2.2.2:4500, <------ RetransmissionÂ
......Â
Peer1_INET:790: negotiation timeout, deleting
Note: When the initiator sends a new IKE SA_INIT to restart the negotiation, the responder FortiGate Peer2 will generate a 'twin connection detected' error message, as Peer2 is still attempting to negotiate the earlier VPN tunnel session.
VPN Peer2 (Responder): Â
Peer2: link is idle Â
Peer2: twin connection detectedÂ
Resolution:
This issue has been identified by Issue #1209209 and is resolved as of FortiOS v7.6.5, v8.0.0, and all later. See also:
FortiOS 7.6.5 - Resolved Issues
FortiOS 8.0.0 - Resolved Issues
Workaround:
Restart the cw_acd process (wireless controller daemon) during a scheduled maintenance window as a workaround until a firmware upgrade can be performed:
FortiGate# execute wireless-controller restart-acd
For FortiGates in a VDOM environment, run the command in the Global VDOM:
FortiGate(global) # execute wireless-controller restart-acdÂ
This operation will reboot wireless controller daemon!Â
  Do you want to continue? (y/n) y
Refer to the following article for further guidance on this process: Technical Tip: How to restart the wireless controller daemon