Description
This article describes an issue where packet drop on an IPsec tunnel interface shows 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, or use a Loopback interface as the termination point for the IPSec tunnel as the loopback interface is not affected by this by design.
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.
The solution is to set up a static route for the remote IPSec VPN gateway IP, directing it through the interface where the IPSec tunnel was established.
config router static
edit 4
set dst 10.x.x.82 255.255.255.255 -> Remote tunnel Gateway IP address.
set gateway 10.z.z.82
set device "port4" <- The VPN tunnel is built over Port4.
next
end
id=20085 trace_id=102 func=print_pkt_detail line=5824 msg="vd-root:0 received a packet(proto=1, 172.16.1.2:2560->172.16.1.1:2048) from local. type=8, code=0, id=2560, seq=3."
id=20085 trace_id=102 func=resolve_ip_tuple_fast line=5905 msg="Find an existing session, id-0002b8d3, original direction"
id=20085 trace_id=102 func=ipd_post_route_handler line=490 msg="out FGTB-A vwl_zone_id 0, state2 0x0, quality 0."
id=20085 trace_id=102 func=ipsecdev_hard_start_xmit line=790 msg="enter IPsec interface-FGTB-A"
id=20085 trace_id=102 func=_ipsecdev_hard_start_xmit line=667 msg="IPsec tunnel-FGTB-A"
id=20085 trace_id=102 func=esp_output4 line=864 msg="IPsec encrypt/auth"
id=20085 trace_id=102 func=ipsec_output_finish line=618 msg="send to 10.x.x.82 via intf-port4"
di sniffer packet any "host 172.16.1.1" 4 0 l
Using Original Sniffing Mode
interfaces=[any]
filters=[host 172.16.1.1]
2023-10-03 10:48:35.218634 FGTB-A out 172.16.1.2 -> 172.16.1.1: icmp: echo request
2023-10-03 10:48:35.224305 FGTB-A in 172.16.1.1 -> 172.16.1.2: icmp: echo reply
2023-10-03 10:48:36.219077 FGTB-A out 172.16.1.2 -> 172.16.1.1: icmp: echo request
2023-10-03 10:48:36.224261 FGTB-A in 172.16.1.1 -> 172.16.1.2: icmp: echo reply
