Troubleshooting Tip: FortiGate blocks the traffic for new VPN Phase2 selectors added to a VPN already working

[MichaelTorres]

Description	This article describes behavior where users are trying to add new VPN phase 2 selectors to a VPN already working but FortiGate blocks new selector's traffic.
Scope	FortiGate VPN Dial-Up.
Solution	Users configure a VPN Dial-Up server with the features add route and device creation enabled. config vpn ipsec phase1-interface     edit <name>         set type dynamic         set net-device enable         set add-route enable     next For the working selectors, validate that FortiGate has a valid route installed in the routing-table through the VPN CPFW-043-ITO001 # get ro info routing-table details 192.168.1.0 Routing table for VRF=0 Routing entry for 192.168.1.0/24 Known via "static", distance 15, metric 0, best * via VPN_EXAMPLE tunnel 1.1.1.1 vrf 0, tun_id For the non-working selectors, validate using the debugs that FortiGate has a valid route and a policy allowing the traffic CPFW-043-ITO001 # id=65308 trace_id=2632 func=print_pkt_detail line=5811 msg="vd-root:0 received a packet(proto=1, 192.168.20.1->172.16.0.1:2048) tun_id=0.0.0.0 from port2. type=8, code=0, id=1, seq=1276." id=65308 trace_id=2632 func=iprope_dnat_check line=5276 msg="in-[port2], out-[]" id=65308 trace_id=2632 func=iprope_dnat_tree_check line=834 msg="len=0" id=65308 trace_id=2632 func=fw_forward_handler line=980 msg="Allowed by Policy-150:" id=65308 trace_id=2632 func=ids_receive line=429 msg="send to ips" id=65308 trace_id=2632 func=ipsecdev_hard_start_xmit line=669 msg="enter IPSec interface VPN_EXAMPLE, tun_id=0.0.0.0" Validate the route for the non-working selector: CPFW-043-ITO001 # get ro info routing-table details 172.16.0.1 Routing table for VRF=0 Routing entry for 172.16.0.0/29 Known via "static", distance 10, metric 0, best * directly connected, Null * directly connected, VPN_EXAMPLE Run the command 'get vpn ipsec tunnel summary' to check the VPN interfaces 'VPN_EXAMPLE_c' 1.1.1.1.:1802 selectors(total,up): 1/1 rx(pkt,err): 7271366/0 tx(pkt,err): 16140651/10164 As the VPN is configured with the features add route and net-device enable, FortiGate will create VPN subinterfaces to route the traffic. This information is not shown in the routing-table. For the working selectors, FortiGate is using the automatic routes created by the VPN with an administrative distance of 15. Technical Tip: How to add automatic route towards the remote subnets when there are multiple Dial-Up...  For the non-working selectors, FortiGate is using manual static routes. Solution: Delete the manual static routes and let FortiGate use the automatic routes created by the VPN. With the automatic routing creation process, FortiGate will use the subinterfaces VPN to route the traffic of the new selectors CPFW-043-ITO001 # id=65308 trace_id=2640 func=print_pkt_detail line=5811 msg="vd-root:0 received a packet(proto=1, 192.168.20.1->172.16.0.1:2048) tun_id=0.0.0.0 from port2. type=8, code=0, id=1, seq=1284." id=65308 trace_id=2640 func=fw_snat_check line=673 msg="NAT disabled by central SNAT policy!" id=65308 trace_id=2640 func=fw_forward_handler line=980 msg="Allowed by Policy-150:" id=65308 trace_id=2640 func=ids_receive line=429 msg="send to ips" id=65308 trace_id=2640 func=ipsecdev_hard_start_xmit line=669 msg="enter IPSec interface VPN_EXAMPLE, tun_id=0.0.0.0" id=65308 trace_id=2640 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel VPN_EXAMPLE_c, tun_id=1.1.1.1, vrf 0"