After Fortigate upgrade v6.4 > v7.0.1 (or later) the S2S-dialup VPNs did not work anymore. Tunnel negotiation is successful and phase 1 and 2 get up. Traffic from spoke is routed into the tunnel, but is seems that the traffic is not received by the hub.
config vpn ipsec phase1-interface edit "S2S_Test" set interface "wan1" set peertype any set remote-gw x.x.x.x set net-device disable set add-route enable (default setting, not visible with "show") set distance 15 (default setting, not visible with "show") ... next end
config router static edit 3 set dst 10.200.1.0 255.255.255.0 set device "S2S_Test" set distance 10 (default setting, not visible with "show") next end
With this configuration we are creating two static routes for the dialup VPN. One through the phase1 setting “set add-route enable” (with distance 15) and the other one through the explicit configured static route (with distance 10).
In 6.4 this hasn’t been a problem because the static route is just “overwriting” the dynamically created route (get router info routing-table database):
S 172.16.190.0/24 [15/0] via 203.0.113.190, s2s-hub_2 S *> 172.16.190.0/24 [10/0] is directly connected, s2s-hub_2
But with 7.0.1 we have a change in the behavior. As described in the New Features Guide there is a new dedicated tunnel IDs that identifies each tunnel.
Routes are linked to the tunnels by the tunnel IDs, replacing the need to have a route tree in the IPsec tunnel list for selecting tunnels by next hop when net-device is disabled. (Consequently, the tunnel search option in phase1 is removed, because tunnels are now clearly identified by the tunnel ID and referenced in the routing table.)
You can see the difference pretty clearly in the routing table (get router info routing-table database) of the hubs with 7.0:
S 172.16.190.0/24 [15/0] via s2s_dialup tunnel 10.0.0.17 S *> 172.16.190.0/24 [10/0] via s2s_dialup tunnel 203.0.113.190
With 7.0 the route for a tunnel needs to be identified by the tunnel id (in this case 10.0.0.17). The active (explicit configured static) route in this example uses the tunnel id 203.0.113.190 which is only valid for a static, but not a dynamic tunnel (where multiple tunnels are using the same gateway IP address). Because of this, dialup vpn configurations with static routes are not working anymore in v7.0.
You can troubleshoot the situation on the 7.0 hub with “diag debug flow”:
Incoming packet from spoke to hub:
id=20085 trace_id=493 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 172.16.190.254:4096->192.168.2.1:2048) from s2s_dialup. type=8, code=0, id=4096, seq=0." id=20085 trace_id=493 func=init_ip_session_common line=5955 msg="allocate a new session-01049dd3" id=20085 trace_id=493 func=vf_ip_route_input_common line=2605 msg="find a route: flag=80000000 gw-192.168.2.1 via root"
Reply packet from hub to spoke:
id=20085 trace_id=494 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 192.168.2.1:4096->172.16.190.254:0) from local. type=0, code=0, id=4096, seq=0." id=20085 trace_id=494 func=resolve_ip_tuple_fast line=5864 msg="Find an existing session, id-01049dd3, reply direction" id=20085 trace_id=494 func=ipsecdev_hard_start_xmit line=625 msg="enter IPSec interface s2s_dialup" id=20085 trace_id=494 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel s2s_dialup" id=20085 trace_id=494 func=ipsec_common_output4 line=792 msg="No matching IPsec selector, drop"
To solve the problem you have to delete the static routes for the dynamic VPNs.
Afterwards traffic runs through the tunnel as expected and output of “diag deb flow” looks as follows (reply packet from hub to spoke):
id=20085 trace_id=510 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 192.168.2.1:2048->172.16.190.254:0) from local. type=0, code=0, id=2048, seq=0." id=20085 trace_id=510 func=resolve_ip_tuple_fast line=5864 msg="Find an existing session, id-010628be, reply direction" id=20085 trace_id=510 func=ipsecdev_hard_start_xmit line=625 msg="enter IPSec interface s2s_dialup" id=20085 trace_id=510 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel s2s_dialup_0" id=20085 trace_id=510 func=esp_output4 line=867 msg="IPsec encrypt/auth" id=20085 trace_id=510 func=ipsec_output_finish line=546 msg="send to 203.0.113.190 via intf-port1"
If the problem is still not solved after cleaning up the routing on your FortiGate, you may want to have a look into our Blog Post IPSec VPN Issues: No traffic through the tunnel caused by dropped ESP packets on the DSL modem.
3,570 total views, 1 views today