This article describes a solution for the IPsec tunnel not coming up on secondary WAN in a dual WAN setup.
Scope
FortiGate.
Solution
When setting up an IPsec dial-up VPN on the second WAN link in the dual wan scenario, the tunnel cannot be established as same as on the primary wan. Running packet capture on user remote IP, ‘Reverse path check fail, drop’ can be observed.
id=65308 trace_id=2 func=print_pkt_detail line=5942 msg="vd-root:0 received a packet (proto=1, X.X.X.X:500->X.X.X.X:2048) tun_id=0.0.0.0 from port6. type=8, code=0, id=1, seq=2." id=65308 trace_id=2 func=init_ip_session_common line=6127 msg="allocate a new session-000003cd" id=65308 trace_id=2 func=iprope_dnat_check line=5480 msg="in-[port6], out-[]" id=65308 trace_id=2 func=iprope_dnat_tree_check line=824 msg="len=0" id=65308 trace_id=2 func=iprope_dnat_check line=5505 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000" id=65308 trace_id=2 func=ip_route_input_slow line=1695 msg="reverse path check fail, drop" id=65308 trace_id=2 func=ip_session_handle_no_dst line=6213 msg="trace"
Checking routing to the user IP using the command ‘get router info routing-table detail X.X.X.X’, the following result can be observed:
Routing table for VRF=0 Routing entry for 0.0.0.0/0 Known via "static", distance 9, metric 0 vrf 0 X.X.X.X, via port6 Routing entry for 0.0.0.0/0 Known via "static", distance 5, metric 0, best * vrf 0 X.X.X.X, via port1, origin 1
The static route via secondary WAN has lower AD so it makes the route to be inactive. Changing the AD to be equal will make the route active and prevent the reverse path check failure issue.
get router info routing-table details X.X.X.X Routing table for VRF=0 Routing entry for 0.0.0.0/0 Known via "static", distance 5, metric 0, best * vrf 0 X.X.X.X, via port1, origin 1 * vrf 0 X.X.X.X, via port6
To change the administrative distance, use the following command:
config router static edit x set distance x end