| Solution |
The error message 'duplicate connection detected on name insert, dropping this connection' in FortiGate indicates that there is a conflict with the VPN configuration name. This error typically occurs when there is an existing VPN configuration with the same name as the one attempting to establish.
To resolve this issue, please follow these steps:
-
Check existing VPN configurations: Verify if there are any VPN configurations with the same name on FortiGate device. Look for any duplicate configurations that might be causing the conflict. Verify both the Phase 1 and Phase 2 configurations.
-
Modify VPN configuration names: If there is any conflict in VPN configurations, modify their names to be unique. Append a different identifier or a trailer to the name of the VPN configuration, ensuring it is different from any existing configurations.
-
Clear existing VPN connections: If any existing VPN connections are using the same name, terminate or delete them before creating the new VPN tunnel. This will allow to establish a fresh connection with the modified and unique VPN configuration.
-
Verify deleted configurations: After deleting any conflicting VPN configurations, double-check that all related routes, policies, and other configurations associated with the previous VPN connections have been completely removed. Sometimes, residual configurations can cause conflicts even if the VPN connection itself has been terminated.
During the IPSEC configuration on FortiGate, sometimes the tunnel remains down even if the configuration is correct. The traffic flow on UDP port 500 can be seen bidirectionally but the phase-1 remains down.
This could be due to a string pattern match issue with another tunnel name.
The first step is to flush the Ike gateway on FortiGate. If the tunnel phase-1 stays down, run the Ike debug:
ike 7:0d9c5d80d68930f9/0000000000000000:7721771: VID FORTIGATE 8299031757A36082C6A621DE00000000
ike 7:0d9c5d80d68930f9/0000000000000000:7721771: negotiation result
ike 7:0d9c5d80d68930f9/0000000000000000:7721771: proposal id = 1:
ike 7:0d9c5d80d68930f9/0000000000000000:7721771: protocol id = ISAKMP:
ike 7:0d9c5d80d68930f9/0000000000000000:7721771: trans_id = KEY_IKE.
ike 7:0d9c5d80d68930f9/0000000000000000:7721771: encapsulation = IKE/none
ike 7:0d9c5d80d68930f9/0000000000000000:7721771: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-
len=256
ike 7:0d9c5d80d68930f9/0000000000000000:7721771: type=OAKLEY_HASH_ALG, val=SHA2_256.
ike 7:0d9c5d80d68930f9/0000000000000000:7721771: type=AUTH_METHOD, val=PRESHARED_KEY.
ike 7:0d9c5d80d68930f9/0000000000000000:7721771: type=OAKLEY_GROUP, val=MODP1024.
ike 7:0d9c5d80d68930f9/0000000000000000:7721771: ISAKMP SA lifetime=86400
ike 7:0d9c5d80d68930f9/0000000000000000:7721771: SA proposal chosen, matched gateway C_P
ike 7:C_P: created connection: 0x10119290 0 205.200.8.221->121.243.5.33:500.
ike 7:C_P: duplicate connection detected on name insert, dropping this connection
ike 7:0d9c5d80d68930f9/0000000000000000:7721771: failed to create a connection
The above debug shows the IKE session was flushed due to name string overlap. The only solution to this case is to delete the tunnel configuration and recreate it. After creating the new tunnel, it should be up on both phases. Make sure the UDP traffic (on port 500) can be seen in both inbound and outbound directions.
Note:
The special characters were removed from the tunnel name (the initial name was abc--abcbc, changed it to abcabcbc), and the tunnel was up and running.
Related article:
Troubleshooting Tip: IPsec VPNs tunnels |
