Skip to main content
kjay
Staff
kjay
Staff
October 14, 2025

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

  • October 14, 2025
  • 0 replies
  • 706 views
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):

 

diagnose debug reset
diagnose debug flow filter clear
diagnose debug flow filter addr 112.170.85.45
diagnose debug flow show function-name enable
diagnose debug console timestamp enable
diagnose debug flow trace start 999
diagnose debug enable


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 because FortiGate processes Policy-Based VPN traffic in a specific way.
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

 

Recommendations:

  • 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.
    Terms & ConditionsAccessibility statement