Description
This article describes an issue where packet drops on an IPsec tunnel interface show the message 'no route to <remote_gateway>, drop' in the debug flow.
Scope
FortiGate.
Solution
When an IPSec tunnel is configured on an interface (i.e., VLAN interface, Physical interface) except for the Loopback interface, the traffic for IKE (tunnel set-up/control plane) and IPSec (encrypted data packet/data plane) should exit out via the same interface on which the IPSec tunnel is built.
If the IPSec VPN is configured on an interface that is not an exit interface for the IPSec traffic, then it will result in packet drops when sending out IPSec traffic, with an error of 'no route to <remote_gateway>, drop' shown in the debug flow for that traffic.
This is a misconfiguration. The correct way is to configure a static route for the remote IPSec VPN gateway IP exiting out of the same interface on which the IPSec tunnel was built (It means that reachability to the remote gateway of the IPsec VPN should be established through the same bound interface not via any other different interface), or use a Loopback interface as the termination point for the IPSec tunnel as the loopback interface is not affected by this by design.
When an IPsec is bound to an interface, traffic must pass through that same interface, except in the case of a loopback interface. So in this case, it is a misconfiguration.
Example:
config system interface
edit "FGTB-A"
set vdom "root"
set ip 172.16.1.2 255.255.255.255
set allowaccess ping https ssh
set type tunnel
set remote-ip 172.16.1.1 255.255.255.0
set snmp-index 13
set interface "port4" -> The VPN tunnel is built over Port4, but the ESP traffic will be routed via Port3.
next
end
get router info routing-table details 10.x.x.82
Routing table for VRF=0
Routing entry for 10.x.0.0/20
Known via "connected", distance 0, metric 0, best
* is directly connected, port3 distance 0 <- Gateway IP address is reachable via Port3.
id=20085 trace_id=10 func=print_pkt_detail line=5824 msg="vd-root:0 received a packet(proto=1, 172.16.1.2:2304->172.16.1.1:0) from local. type=0, code=0, id=2304, seq=4."
id=20085 trace_id=10 func=resolve_ip_tuple_fast line=5905 msg="Find an existing session, id-0001a694, reply direction"
id=20085 trace_id=10 func=ipd_post_route_handler line=490 msg="out FGTB-A vwl_zone_id 0, state2 0x0, quality 0."
id=20085 trace_id=10 func=ipsecdev_hard_start_xmit line=790 msg="enter IPsec interface-FGTB-A"
id=20085 trace_id=10 func=_ipsecdev_hard_start_xmit line=667 msg="IPsec tunnel-FGTB-A"
id=20085 trace_id=10 func=esp_output4 line=672 msg="no route to 10.x.x.82, drop" <- The IP-address '10.x.x.82' is Gateway IP address.
Note:
At times, the issue may arise due to having the net-device disabled in a redundant hub-and-spoke VPN setup (without ADVPN). This can lead to symptoms similar to the debug output shown below. In this case, enable the net-device in hub and spoke to allow proper routing from hub to spoke or from spoke-to-spoke traffic.
id=65308 trace_id=84 func=print_pkt_detail line=6007 msg="vd-root:0 received a packet(proto=6, 10.10.11.1:443 >10.72.1.1:53697) tun_id=0.0.0.0 from local. flag [S.], seq 3892005093, ack 1768108087, win 65535"
id=65308 trace_id=84 func=resolve_ip_tuple_fast line=6108 msg="Find an existing session, id-00e7f202, reply direction"
id=65308 trace_id=84 func=ip_session_core_in line=6730 msg="dir-1, tun_id=175.137.59.125"
id=65308 trace_id=84 func=ipsecdev_hard_start_xmit line=669 msg="enter IPSec interface Branch_P tun_id=175.137.59.125"
id=65308 trace_id=84 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel Branch_P_d, tun_id=175.137.59.125, vrf 0"
id=65308 trace_id=84 func=esp_output4 line=651 msg="no route to 175.137.59.125, drop"
Related document:
Redundant hub and spoke VPN
