Technical Tip: Workaround for local traffic being sent through the tunnel when using Policy-Based IPsec VPN

[kjay]

Description	This article describes a phenomenon that can cause certain types of local traffic (such as DNS queries) to be sent through the VPN tunnel instead of the intended routing path when using a policy-based IPsec VPN. This can occur even when the tunnel is down, and in some cases, the traffic may still be redirected through a different tunnel after the affected tunnel has been deleted. When this issue occurs, ping traffic destined for the gateway may also fail for the same reason.
Scope	FortiGate is configured with a policy-based IPsec VPN.
Solution	Example Configuration: config firewall policy     edit 16         set srcintf "internal"         set dstintf "wan1"         set action ipsec         set srcaddr "all"         set dstaddr "all"         set service "ALL"         set vpntunnel "icheon19_PT"     next end config vpn ipsec phase1     edit "icheon19_PT"         set interface "wan1"         set peertype any         set proposal 3des-md5         set localid "icheon19_PT"         set dhgrp 2         set remote-gw <remote-gateway>         set psksecret <secret>     next end config vpn ipsec phase2     edit "icheon19_PT"         set phase1name "icheon19_PT"         set proposal 3des-md5         set dhgrp 2         set auto-negotiate enable         set keylifeseconds 28800         set src-subnet 192.239.19.0 255.255.255.0         set dst-subnet 192.239.23.0 255.255.255.0     next end Observed Behavior (debug flow output): id=65308 trace_id=41 func=print_pkt_detail line=5818 msg="vd-root:0 received a packet(proto=1, 112.170.85.45:27->112.170.85.1:2048) tun_id=0.0.0.0 from local. type=8, code=0, id=27, seq=0." id=65308 trace_id=41 func=init_ip_session_common line=5995 msg="allocate a new session-0017a373" id=65308 trace_id=41 func=ipsec_tunnel_output4 line=1187 msg="enter IPsec tunnel-icheon19_PT" id=65308 trace_id=41 func=ipsec_common_output4 line=785 msg="No matching IPsec selector, drop" Root Cause. This issue occurs due to the way FortiGate processes Policy-Based VPN traffic. FortiGate evaluates the policy’s source and destination addresses before checking the Phase 2 selectors. As a result, if the policy’s address objects are too broad (e.g., set to all), local traffic may incorrectly match the VPN policy and be routed into the tunnel. Workaround. To avoid this behavior, configure the policies srcaddr and dstaddr to match the Phase 2 selectors. This ensures that only traffic matching the defined subnets is encrypted and sent through the tunnel. Corrected Configuration Example: config firewall policy     edit 16         set srcintf "internal"         set dstintf "wan1"         set action ipsec         set srcaddr "192.239.19.0/24"         set dstaddr "192.239.23.0/24"         set service "ALL"         set vpntunnel "icheon19_PT"     next end config vpn ipsec phase2     edit "icheon19_PT"         set phase1name "icheon19_PT"         set proposal 3des-md5         set dhgrp 2         set auto-negotiate enable         set keylifeseconds 28800         set src-subnet 192.239.19.0 255.255.255.0         set dst-subnet 192.239.23.0 255.255.255.0     next end Recommendation. Remove any unused or inactive VPN tunnels to prevent routing conflicts or unintended tunnel matches. For better routing control and predictability, it is recommended to use an Interface-Based IPsec VPN instead of a Policy-Based VPN.