Troubleshooting Tip: Not able to reach the local network via IPsec when the IPsec tunnel is UP

In this scenario, it is not possible to reach the local network despite the tunnel being active. Only incoming bytes are observed; no return traffic, and sent bytes remain at zero.

Topology:

192.168.0.0/16 — FortiGate — IPsec — FortiGate1 10.33.0.0/16

In this topology, IP 10.33.205.201 attempts to reach 192.168.2.28 over IPsec. Routes are configured but appear inactive.

Debug logs:

Firewall # get router info routing-table details 10.33.0.0

Routing table for VRF=0
Routing entry for 10.33.0.0/16
Known via "static", distance 254, metric 0, best
* directly connected, Null  <---- Blackhole route is showing as active route for 10.33.0.0.

Routing entry for 10.33.0.0/16
Known via "static", distance 10, metric 0
via xyz tunnel 10.0.0.4 vrf 0 inactive, tun_id <-----

For VPN debugging troubleshoot commands, refer to Troubleshooting Tip: IPsec VPN tunnels.

Note: The debugging results below were obtained by enabling the debugging processes explained in the article linked above.

 Firewall # id=65308 trace_id=23 func=print_pkt_detail line=5879 msg="vd-QANA:0 received a packet(proto=1, 10.33.205.201:1->192.168.2.8:2048) tun_id=10.0.0.4 from WV--TO--SAV. type=8, code=0, id=1, seq=
2078."
id=65308 trace_id=23 func=init_ip_session_common line=6063 msg="allocate a new session-48eba2b1"
id=65308 trace_id=23 func=ip_route_input_slow line=2268 msg="reverse path check fail, drop"
id=65308 trace_id=23 func=ip_session_handle_no_dst line=6149 msg="trace"
id=65308 trace_id=24 func=print_pkt_detail line=5879 msg="vd-QANA:0 received a packet(proto=1, 10.33.205.201:1->192.168.2.8:2048) tun_id=10.0.0.4 from xyz. type=8, code=0, id=1, seq=2079."
id=65308 trace_id=24 func=init_ip_session_common line=6063 msg="allocate a new session-48ebac92"
id=65308 trace_id=24 func=ip_route_input_slow line=2268 msg="reverse path check fail, drop"   <---
id=65308 trace_id=24 func=ip_session_handle_no_dst line=6149 msg="trace"

 Firewall # id=65308 trace_id=25 func=print_pkt_detail line=5879 msg="vd-QANA:0 received a packet(proto=1, 10.33.205.201:1->192.168.2.8:2048) tun_id=10.0.0.4 from WV--TO--SAV. type=8, code=0, id=1, seq=
2080."
id=65308 trace_id=25 func=init_ip_session_common line=6063 msg="allocate a new session-48ebb7ad"
id=65308 trace_id=25 func=ip_route_input_slow line=2268 msg="reverse path check fail, drop"
id=65308 trace_id=25 func=ip_session_handle_no_dst line=6149 msg="trace"

Solution:

Verify if the IPsec VPN tunnel interface is configured for link monitor or SDWAN performance SLA. Refer to: Technical Tip: How to identify inactive routes in the Routing Table 

Restart the routing table during the scheduled downtime or maintenance window. The command to restart the router process:

execute router restart

Another method is to bounce the tunnel. Use the commands below to bring down and bring up the tunnel to resolve the issue. This does not require a downtime to restart the process, as a specific phase2 name is specified.

diagnose vpn tunnel up <phase2 name>

diagnose vpn tunnel down <phase2 name>

Alternatively, flush the VPN tunnel with the following command.

diagnose vpn tunnel flush <phase2 name>

Note: Since this is a global command, in a multi-VDOM setup, it must be executed from the global VDOM. This should be used during a maintenance window since it impacts traffic across all VDOMs.

Related articles:

Technical Tip: Use of Black hole route in site to site IPsec VPN scenarios

Troubleshooting Tip: Routing issue: reverse path check fail (bad source)

Troubleshooting Tip: Route shows inactive when SD-WAN Performance SLA Configured