Description
This article describes how to resolve the error 'Failed to find IPsec Common' received for IPSEC tunnel formed between FortiGates.
If this error is appearing as per below logs:
2021-03-22 23:43:40 id=20085 trace_id=1607 func=print_pkt_detail line=5618 msg="vd-Wafir-FW:0 received a packet(proto=1, 172.27.60.27:1->172.30.7.10:2048) from port25.999. type=8, code=0, id=1, seq=5389."
2021-03-22 23:43:40 id=20085 trace_id=1607 func=resolve_ip_tuple_fast line=5698 msg="Find an existing session, id-0557d5a0, original direction"
2021-03-22 23:43:40 id=20085 trace_id=1607 func=ipv4_fast_cb line=53 msg="enter fast path"
2021-03-22 23:43:40 id=20085 trace_id=1607 func=ipsecdev_hard_start_xmit line=788 msg="enter IPsec interface-Test-SpokeVPN"
2021-03-22 23:43:40 id=20085 trace_id=1607 func=ipsecdev_hard_start_xmit line=853 msg="Failed to find IPsec Common: Test-SpokeVPN"
Solution
Do below change on the IPsec phase 1 on both sides.
# config vpn ipsec phase1-interface
edit "phase1Name"
set exchange-interface-ip enable
end
Further Information
Please note that the 'Failed to find IPsec Common' message generally only appears when the following is set on an IPsec tunnel configuration:
- FortiOS version is 6.4 or earlier.
- VPN Type is set to dynamic (AKA "Dialup User" in the Web UI).
- net-device is set to disable and tunnel-search is set to nexthop (commonly used with BGP-based configurations).
- exchange-interface-ip is set to disable and the configuration is not using ADVPN (i.e. auto-discovery-*).
- mode-config is not in-use (commonly used for Remote-Access VPNs using FortiClient).
Dialup IPsec tunnels on the FortiGate allow administrators to configure one VPN tunnel that many devices can connect to. This is often used for end-client remote-access VPNs, but it also sees frequent usage for Hub-and-Spoke VPN tunnels as well (such as ADVPN).
However, when multiple devices are connecting to a shared VPN, the FortiGate must be able to determine which connected VPN member should be used when routing traffic to a particular subnet. In FortiOS 6.4 and earlier, when using net-device disable, this is accomplished using a route tree, and this route tree can be viewed using the command diagnose vpn tunnel list name <VPN Tunnel name>:
With that in mind, the 'Failed to find IPsec Common' message will appears in the iked debugs whenever the FortiGate attempts to route traffic to a next-hop that does not exist in the above route-tree. The following is an example that demonstrates what happens when the route-tree does NOT have an appropriate IP address to match the static route's next-hop IP address:
To briefly explain the above image:
1. The 'dialup' VPN tunnel interface is set with a remote tunnel IP of 172.16.1.254/24, which is perfectly fine in most scenarios. Notably however, exchange-interface-ip is not enabled in this scenario.
2. The IPv4 route tree is missing an entry for 172.16.1.100, the IP address of the remote VPN client FortiGate connected to the hub FortiGate.
3. A route is present on the hub that references 172.16.1.100 as the next-hop gateway address for destination 1.2.3.4/32.
4. The hub FortiGate attempts to ping 1.2.3.4, and it routes traffic to the 'dialup' IPsec tunnel. But because the route tree is missing an entry for 172.16.1.100, it fails and reports 'Failed to find IPsec Common: dialup'
As a side note, FortiOS 7.0 and later see a change to the dialup IPsec tunnel design, such that route trees are no longer used (a 'tun ID' is used instead). This issue should no longer occur on these later FortiOS versions.
