|
Original topology:
Topology after migration:
Note: The issue described in this article is uncommon. The most common cause of an IPsec tunnel failing to establish after migration is a configuration error. It is strongly recommended to double-check the configuration and run a flow trace before proceeding. See this article: Troubleshooting Tip: Troubleshooting IPsec site-to-site tunnel connectivity.
Symptoms:
- The configuration of the new tunnel is verified to be correct.
- Replacing the FortiGate with the previous device brings the tunnel up again.
- Incoming IKE (UDP port 500) packets from the remote gateway are seen in FortiGate.
diagnose sniffer packet any '(port 500 or 4500) and host 192.0.2.27' 4 5
interfaces=[any]
filters=[port 500]
29.394767 port2 in 192.0.2.27.500 -> 198.51.100.26.500: udp 512
60.414161 port2 in 192.0.2.27.500 -> 198.51.100.26.500: udp 512
91.453565 port2 in 192.0.2.27.500 -> 198.51.100.26.500: udp 512
122.473002 port2 in 192.0.2.27.500 -> 198.51.100.26.500: udp 512
152.762539 port2 in 192.0.2.27.500 -> 198.51.100.26.500: udp 512
- The debug flow trace does not show the incoming packets seen in the sniffer.
diagnose debug reset
diagnose debug flow filter saddr 192.0.2.27
diagnose debug enable
diagnose debug flow trace start 2
<no output>
- Similar to the flow trace, incoming IKE packets (in this case 192.0.2.27:500->198.51.100.26:500) are not seen in IKE debug messages. Depending on the tunnel configuration, outgoing IKE messages for the tunnel may be seen with 'RETRANSMIT_SA_INIT'.
diagnose debug reset
diagnose debug ike -1
diagnose debug enable
ike V=root:0:Tunnel: request is on the queue
ike 0:Tunnel:7559: out <hexdump>
ike V=root:0:Tunnel:7559: sent IKE msg (RETRANSMIT_SA_INIT): 198.51.100.26:500->192.0.2.27:500, len=512, vrf=0, id=a937ac429a4e8928/0000000000000000, oif=10
ike V=root:0:Tunnel:Tunnel-P2: IPsec SA connect 10 198.51.100.26->192.0.2.27:0
ike V=root:0:Tunnel:Tunnel-P2: using existing connection
ike V=root:0:Tunnel:Tunnel-P2: traffic triggered, serial=1 1:10.56.253.1:2048->1:10.120.253.1:0
ike V=root:0:Tunnel:Tunnel-P2: config found
ike V=root:0:Tunnel: request is on the queue
ike V=root:0:Tunnel:Tunnel-P2: IPsec SA connect 10 198.51.100.26->192.0.2.27:0
ike V=root:0:Tunnel:Tunnel-P2: using existing connection
ike V=root:0:Tunnel:Tunnel-P2: traffic triggered, serial=1 1:10.56.253.1:2048->1:10.120.253.1:0
ike V=root:0:Tunnel:Tunnel-P2: config found
ike V=root:0:Tunnel: request is on the queue
ike V=root:0:Tunnel:7559: negotiation timeout, deleting
ike V=root:Tunnel Negotiate SA Error: ike negotiation timeout
If the incoming IKE packets do generate IKE messages on the FortiGate, it does not match the ISP issue described by this article. In that case, proceed with general IPsec troubleshooting steps as if this is a new deployment
To disable the debug, use the following CLI command:
diagnose debug reset
- The packets have a destination MAC address matching the previous firewall, which does not match the FortiGate's external address. The MAC address can be seen by taking a packet capture with verbosity level 6. The destination MAC address appears in the first 6 bytes of the Ethernet frame. In the example below, the incoming frame has destination MAC address 'AA:AA:AA:11:11:11'.
diagnose sniffer packet port2 '(port 500 or 4500) and host 192.0.2.27' 6 10
interfaces=[port2]
filters=[(port 500 or 4500) and host 192.0.2.27]
6.068196 port2 -- 192.0.2.27.500 -> 198.51.100.26.500: udp 512
0x0000 aaaa aa11 1111 eeee ee11 1111 0800 4500 ..............E.
0x0010 021c f7d2 0000 3f11 9595 c000 021b c633 ......?........3
...
Note: A packet capture taken on the 'any' interface does not show the destination MAC address. The interface or VLAN receiving the notable traffic must be specified.
Resolution:
The issue occurs because the directly connected upstream router has cached the destination MAC of the old external firewall for the IKE session and is not updating it with the newly observed MAC address. Reboot or power cycle the upstream router or modem (labelled 'ISP Router' in the topologies above) to resolve the issue. This will update the destination MAC address sent by the directly connected device.
diagnose sniffer packet port2 '(port 500 or 4500) and host 192.0.2.27' 6 10
interfaces=[port2]
filters=[(port 500 or 4500) and host 192.0.2.27]
26.379487 port2 -- 192.0.2.27.500 -> 198.51.100.26.500: udp 512
0x0000 aaaa aa22 2222 eeee ee11 1111 0800 4500 ..."""........E.
0x0010 021c f7e2 0000 3f11 9585 c000 021b c633 ......?........3
...
If the destination MAC address is correctly updated but the tunnel still does not come up, collect IKE debugs and follow general IPsec troubleshooting steps.
If it is not possible to reboot or power cycle the old device, updating the FortiGate's mac address for the interface may work around the issue. See this article: Technical Tip: How to change the Interface's MAC addresses on FortiGate.
Related documents:
Troubleshooting Tip: Troubleshooting IPsec site-to-site tunnel connectivity
Technical Tip: FortiGate IPsec VPN resource list
Troubleshooting Tip: Disabling FortiGate IPsec tunnel for five minutes as a workaround to an ISP sta...
Blocking unwanted IKE negotiations and ESP packets with a local-in policy
|
