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"
Note:
When using tunnel interface is bound to a loopback interface and loopback-asymroute setting is disabled under VPN phase1 configuration, the "no route to x.x.x.x, drop" error can be faced.
This due to disable the loopback-asymroute pushed down the loopback interface index as tunnel's bound_if, causing traffic route lookup failure.
For example:
When ESP traffic is working with 'loopback-asymroute enabled' the VPN tunnel list shows the bound_if=0, which follow the routing table to reach the VPN peer gateway (10.20.30.6).
FGTVM(root) # diagnose vpn tunnel list name HQ-VPN-HUB
list ipsec tunnel by names in vd 0
------------------------------------------------------
name=HQ-VPN-HUB ver=1 serial=3 10.20.30.1:0->10.20.30.6:0 nexthop=10.10.1.1 tun_id=10.20.30.6 tun_id6=::10.20.30.6 dst_mtu=1500 dpd-link=off weight=1
bound_if=0 real_if=58 lgwy=static/1 tun=intf mode=auto/1 encap=none/552 options[0228]=npu frag-rfc run_state=0 role=sync-primary accept_traffic=0 overlay_id=0
proxyid_num=1 child_num=0 refcnt=4 ilast=213224 olast=213226 ad=/0
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=on-idle on=0 idle=20000ms retry=3 count=0 seqno=6
natt: mode=none draft=0 interval=0 remote_port=0
fec: egress=0 ingress=0
proxyid=HQ-VPN-HUB proto=0 sa=0 ref=2 serial=3 auto-negotiate
src: 0:0.0.0.0-255.255.255.255:0
dst: 0:0.0.0.0-255.255.255.255:0
run_tally=0
FGTVM(root) # get router info routing-table details 10.20.30.1
Routing table for VRF=0
Routing entry for 10.20.30.1/32
Known via "connected", distance 0, metric 0, best
* is directly connected, LoopBack
FGTVM(root) # get router info routing-table details 10.20.30.6
Routing table for VRF=0
Routing entry for 10.20.30.6/32
Known via "bgp", distance 20, metric 0, best
Last update 02:19:28 ago
* vrf 0 10.30.2.1 priority 1 (recursive is directly connected, INT_WAN_PRI)
Then, if 'loopback-asymroute' is disabled, 'bound_if' is changed to the loopback index interface, causing the IPsec route lookup failure.
FGTVM(root) # config vpn ipsec phase1-interface
FGTVM(root) # edit HQ-VPN-HUB
FGTVM(root) # set loopback-asymroute disable <-----
FGTVM(root) # end
FGTVM(root) # diagnose vpn tunnel list name HQ-VPN-HUB
list ipsec tunnel by names in vd 0
------------------------------------------------------
name=HQ-VPN-HUB ver=1 serial=3 10.20.30.1:0->10.20.30.6:0 nexthop= tun_id=10.20.30.6 tun_id6=::10.20.30.6 dst_mtu=1500 dpd-link=on weight=1
bound_if=30 real_if=58 lgwy=static/1 tun=intf mode=auto/1 encap=none/552 options[0228]=npu frag-rfc run_state=0 role=sync-primary accept_traffic=1 overlay_id=0
proxyid_num=1 child_num=0 refcnt=5 ilast=8 olast=1 ad=/0
stat: rxp=1 txp=12 rxb=64 txb=816
dpd: mode=on-idle on=1 idle=20000ms retry=3 count=0 seqno=7
natt: mode=none draft=0 interval=0 remote_port=0
fec: egress=0 ingress=0
proxyid=HQ-VPN-HUB proto=0 sa=1 ref=3 serial=3 auto-negotiate
src: 0:0.0.0.0-255.255.255.255:0
dst: 0:0.0.0.0-255.255.255.255:0
SA: ref=4 options=18027 type=00 soft=0 mtu=1280 expire=42809/0B replaywin=1024
seqno=1 esn=0 replaywin_lastseq=00000002 qat=0 rekey=0 hash_search_len=1
life: type=01 bytes=0/0 timeout=42928/43200
dec: spi=54d6b802 esp=aes key=16 80100fc1dca135f75f1814d9054c850f
ah=sha256 key=32 7513a91ec18124c27a4a7b4d9202b6eef43a86323ee38c580839c8ad314dcd9ba
enc: spi=8836b66b esp=aes key=16 a829c603441478fcdbdfbd66861a5271
ah=sha256 key=32 c61647de6b9c00e329f7460321bebd82e14e23aa212a643b50990ad7c56e1bcb
dec:pkts/bytes=2/128, enc:pkts/bytes=12/816
npu_flag=02 npu_rgwy=10.20.30.6 npu_lgwy=10.20.30.1 npu_selid=7 dec_npuid=1 enc_npuid=0
run_tally=0
FGTVM(root) # diagnose ip address list
...
IP=10.20.30.1->10.20.30.1/255.255.255.255 index=40 devname=LoopBack
On debug flow the route lookup failure is shown:
2025-03-12 12:06:33 id=65308 trace_id=3 func=print_pkt_detail line=5820 msg="vd-root:0 received a packet(proto=89, 172.16.19.1:0->224.0.0.5:0) tun_id=0.0.0.0 from local. "
2025-03-12 12:06:33 id=65308 trace_id=3 func=resolve_ip_tuple_fast line=5903 msg="Find an existing session, id-27443359, original direction"
2025-03-12 12:06:33 id=65308 trace_id=3 func=ipsecdev_hard_start_xmit line=669 msg="enter IPSec interface HQ-VPN-HUB, tun_id=0.0.0.0"
2025-03-12 12:06:33 id=65308 trace_id=3 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel HQ-VPN-HUB, tun_id=10.20.30.6, vrf 0"
2025-03-12 12:06:33 id=65308 trace_id=3 func=esp_output4 line=655 msg="no route to 10.20.30.6, drop" <----- The loopback interface is used to do the route lookup causing the failure even when route to gateway is properly installed on routing-table.
FGTVM(root) # get router info routing-table details 10.20.30.6
Routing table for VRF=0
Routing entry for 10.20.30.6/32
Known via "bgp", distance 20, metric 0, best
Last update 02:30:28 ago
* vrf 0 10.30.2.1 priority 1 (recursive is directly connected, INT_WAN_PRI)
This is a reported issue and resolved on FortiOs version 7.4.2.
Resolved issues - page 53: '930278' - Setting loopback-asymroute disable in the phase 1 configuration pushes down the loopback interface index as tunnel's bound_if, causing traffic route lookup failure.
Related documents:
