| 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 that 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
Removed the IP address from the FortiGate B and the tunnel comes up.  |
