Troubleshooting Tip: SD-WAN policy matched but incorrect outbound interface selected

Description

This article describes the scenario where traffic matches the correct SD-WAN rule, but FortiGate kernel selects an incorrect outbound interface, which is not part of the matched SD-WAN rule.

Scope

FortiGate.

Solution

In this scenario, the VPN tunnel is UP and a static default route is configured towards the remote IPSEC tunnel. An SD-WAN rule has been created to steer traffic based on defined rules.

Scenario Details:
Destination Address: 10.10.10.130.
Kernel Route Table:

tab=254 vf=0 scope=0 type=1 proto=11 prio=1 0.0.0.0/0.0.0.0/0->0.0.0.0/0 pref=0.0.0.0
gwy=196.170.18.1 flag=04 hops=0 oif=48(VPN1-ISP1)
gwy=197.180.19.1 flag=04 hops=0 oif=51(VPN1-ISP2)
gwy=198.190.20.2 flag=04 hops=0 oif=54(VPN1-ISP3)
gwy=10.0.0.1 flag=04 hops=0 oif=45(VPN2-ISP1)
gwy=10.0.0.2 flag=04 hops=0 oif=49(VPN2-ISP2)
gwy=10.0.0.3 flag=04 hops=0 oif=52(VPN2-ISP3)

Expected Interface: VPN2-ISP1.
Observed Interface: VPN1-ISP1.

A default static route exists toward multiple outbound interfaces. To manage traffic paths, an SD-WAN rule has been configured.

SD-WAN Rule Used: Rule No. 4.
Rule Criteria: Source = All, Destination = All.
Interfaces Assigned to Rule: VPN2-ISP1, VPN2-ISP2, VPN2-ISP3.
Behavior: Since Rule No. 4 is on top of the SD-WAN rule list, traffic matching this rule is expected to follow one of the interfaces specified in this rule.
Observation: Despite the rule match, traffic destined for 10.10.10.130 is routed via VPN1-ISP1 instead of the expected VPN2-ISP1, VPN2-ISP2, or VPN2-ISP3.

A debug flow filter can be used to verify which SD-WAN rule ID the traffic is matching.

Debug flow:

2026-03-04 22:16:20 id=65308 trace_id=19 func=print_pkt_detail line=5811 msg="vd-root:0 received a packet(proto=17, 10.17.106.112:46715->10.10.10.130:53) tun_id=0.0.0.0 from lan_vlan. "
2026-03-04 22:16:20 id=65308 trace_id=19 func=init_ip_session_common line=5995 msg="allocate a new session-012f81ce"
2026-03-04 22:16:20 id=65308 trace_id=19 func=iprope_dnat_check line=5276 msg="in-[lan_vlan], out-[]"
2026-03-04 22:16:20 id=65308 trace_id=19 func=iprope_dnat_tree_check line=834 msg="len=0"
2026-03-04 22:16:20 id=65308 trace_id=19 func=iprope_dnat_check line=5288 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
2026-03-04 22:16:20 id=65308 trace_id=19 func=rpdb_srv_match_input line=1050 msg="Match policy routing id=2131230724: to 10.10.10.130 via ifindex-48"
2026-03-04 22:16:20 id=65308 trace_id=19 func=vf_ip_route_input_common line=2611 msg="find a route: flag=04000000 gw-196.170.18.1 via VPN1-ISP1"
2026-03-04 22:16:20 id=65308 trace_id=19 func=iprope_fwd_check line=766 msg="in-[lan_vlan], out-[VPN1-ISP1], skb_flags-02000000, vid-0, app_id: 0, url_cat_id: 0"
2026-03-04 22:16:20 id=65308 trace_id=19 func=__iprope_check_one_policy line=2243 msg="policy-16 is matched, act-accept"

In the debug flow filter, it is clearly observed that the traffic matches policy route ID 2131230724, which corresponds to SD-WAN rule ID 4. However, the selected outgoing interface is VPN1-ISP1, which is not part of SDWAN rule ID 4.
From the forward traffic logs, it is also observed that VPN1-ISP1 is used as the egress interface, even though SD-WAN rule ID 4 is matched.

Packet capture also shows that the traffic egresses via VPN1-ISP1.

SpokeFW1 # diagnose sniff packet any 'host 10.10.10.130 and port 53' 4 0 l
interfaces=[any]
filters=[host 10.129.15.130 and port 53]
2026-03-04 22:59:22.237583 lan_vlan in 10.117.206.33.48703 -> 10.10.10.130.53: udp 41
2026-03-04 22:59:22.237749 VPN1-ISP1 out 10.117.206.33.48703 -> 10.10.10.130.53: udp 41

From the output of diagnose firewall proute list:

id=2131230724(0x7f080004) vwl_service=4(TO_HUB1) vwl_mbr_seq=2 3 4 dscp_tag=0xfc 0xfc flags=0x0 tos=0x00 tos_mask=0x00 protocol=0 sport=0-65535
iif=0(any) dport=1-65535 path(4) oif=0(any) oif=45(VPN2-ISP1) oif=49(VPN2-ISP2) oif=52(VPN2-ISP3) --> Observing 4 Path even when the rule only has 3.
source(1): 0.0.0.0-255.255.255.255
destination(1): 0.0.0.0-255.255.255.255

SD-WAN rule has only 3 members:

    edit 4
        set name "TO_HUB1
        set dst "all"
        set src "all"
        set priority-members 2 3 4
    next

In case of SD-WAN rule 5, the paths are shown correctly:

id=2131230735(0x7f08000f) vwl_service=5(To_HUB2) vwl_mbr_seq=10 11 12 dscp_tag=0xfc 0xfc flags=0x0 tos=0x00 tos_mask=0x00 protocol=0 sport=0-65535

iif=0(any) dport=1-65535 path(3) oif=48(VPN1-ISP1) oif=51(VPN1-ISP2) oif=54(VPN1-ISP3) >> Observing three paths as configured
source(1): 0.0.0.0-255.255.255.255
destination(1): 0.0.0.0-255.255.255.255
hit_count=1 last_used=2026-03-04 22:03:57

    edit 5
        set name "To_HUB2
        set dst "all"
        set src "all"
        set priority-members 10 11 12
    next

The issue is resolved after rebooting the FortiGate.
Post-reboot logs show only three paths, as expected:

id=2130771972(0x7f010004) vwl_service=4(TO_HUB1) vwl_mbr_seq=2 3 4 dscp_tag=0xfc 0xfc flags=0x0 tos=0x00 tos_mask=0x00 protocol=0 sport=0-65535

iif=0(any) dport=1-65535 path(3) oif=45(VPN2-ISP1) oif=49(VPN2-ISP2) oif=52(VPN2-ISP3) --> There is no 'any' interface.
source(1): 0.0.0.0-255.255.255.255
destination(1): 0.0.0.0-255.255.255.255

Workaround:
Reboot.
Turning off ADVPN shortcuts seems to be a valid workaround.

Solution:

This is caused in some cases when the FortiOS kernel sends a dummy interface index(0). The fix for this issue is included in FortiOS v7.4.8 and v7.6.3.