| Description |
This article describes the troubleshooting steps and example of an IPSec tunnel which is not coming up and the following error is seen in the IKE debug:
ike 0: remote address <x.x.x.x> <----- Does not match. configuration address <y.y.y.y> <----- Drop or could not send IKE. |
| Scope | FortiGate all versions. |
| Solution |
There might be the following error in the IKE debug:
ike 0: remote address <x.x.x.x> does not match configuration address <y.y.y.y>, drop
Reason: This error comes when the IP address of the peer exists on the firewall either as a VIP or IP pool or on any interface.
Scenario: IPSec tunnel between FortiGate A and FortiGate B.
FortiGate A (10.9.15.8)----IPSec_Tunnel----(10.9.15.83) FortiGate B.
On FortiGate B, someone mistakenly defined the WAN IP address of the peer which is FortiGate A on the firewall either as VIP or IP Pool or IP address on the interface.
In this example, IP address 10.9.15.8 on the loopback.
config system interface edit "Loopback" set vdom "root" set ip 10.9.15.8 255.255.255.255 <-- IP address of the peer. set type loopback set role lan set snmp-index 16 next end
The IPSec tunnel is not coming up and IKE debug showing the following error:
ike 0:Local-Fortigate:12: sent IKE msg (P1_RETRANSMIT): 10.9.15.83:500->10.9.15.8:500, len=192, vrf=0, id=f28fcb1b47fa91c2/35d50e138447d095 ike 0: comes 10.9.15.83:500->10.9.15.8:500,ifindex=3,vrf=0.... ike 0: IKEv1 exchange=Identity Protection id=f28fcb1b47fa91c2/35d50e138447d095 len=192 vrf=0 ike 0:Local-Fortigate:12: remote address 10.9.15.83 does not match configuration address 10.9.15.8, drop ike 0:Local-Fortigate:11: negotiation timeout, deleting ike 0:Local-Fortigate: schedule auto-negotiate ike 0:Local-Fortigate:12: negotiation timeout, deleting ike 0:Local-Fortigate: connection expiring due to phase1 down
Remove the IP address from either VIP, IP-pool, or the interface on the FortiGate B, and the tunnel came up.
Scenario 2: In another scenario, this error comes up if the remote FortiGate is reverting, and it is being NAT-ed in between.
It is possible to check in IKE debugs as mentioned in this KB article: Troubleshooting Tip: IPSEC Tunnel (debugging IKE)
It is possible to see FortiGateA (10.9.15.8) is getting reverted from FortiGateB (10.9.15.83) as the remote address 166.144.101.17, as it is being NATed in between, or could be an issue on the ISP side.
Scenario 3: No output shown on the IKE debug when a VIP is configured on UDP Port 500/4500.
FortiGate A (10.47.18.84) ---Dialup_IPsec_Tunnel---(10.47.20.139)Fortigate B
FortiGate B is a dial-up user. On FortiGate A, the administrator configured a VPN server on the FortiGate, and the VIP is configured to map UDP ports 500 and 4500 on its WAN interface to an internal IP.
When running IKE debug on FortiGate A and initiating the tunnel from FortiGate B, no debug output appears, and the tunnel does not come up.
Run sniffer for port 500 or 4500 on FortiGate A. The output shows that IKE packets are reaching FortiGate A, but no response is sent back to the peer.
Filter the sessions by source IP and list them using the command below.
diagnose sys session filter src <x.x.x.x> diagnose sys session list
The output shows that the IP address of FortiGate A’s local IPsec gateway is being DNATed to a different IP address based on the VIP configuration.
Remove or disable the VIP configuration that overlaps with UDP ports 500 and 4500 on the interface used for the IPsec tunnel, and the tunnel came up.
Another option that is available in v7.0.0 and above is to configure the FortiGate to listen on a custom port for IKE destined to the local FortiGate for IPsec negotiation.
This option can be used if the VIP is required to be in place:
config system settings set ike-port <integer> <----- UDP port for IKE/IPsec traffic (1024 - 65535, default = 500). end
Related document: |
