Technical Tip: SD-WAN Health Check GRE Traffic on FortiGate 6000 Series

Description

This article describes the expected behavior for SD-WAN SLA probes over GRE members traversing different FPCs in a 6K Chassis.

Scope

FortiGate 6K Chassis.

Solution

When implementing SD-WAN on a FortiGate 6000 series firewall with GRE tunnels as SD-WAN member interfaces, a potential issue can arise with Performance SLA monitoring.

If an HTTP probe or ICMP probe is configured for SLA health checks, the probe traffic may egress from one FPC and ingress on a different FPC. This behavior can cause the GRE tunnel (SD-WAN member) to be marked as down, even when the underlying path remains operational.

Master FPC: FPC02.

Health check IP: 4.4.4.4.

Tunnel name: GRE1_TEST_SY_U.

FortiGate-6000F (global) # diagnose load-balance status

==========================================================================

MBD SN: F6KF31T01xxxxxx

Primary FPC Blade: slot-2

• On capture, it can be seen that traffic goes via FPC2 but comes back in FPC4, hence traffic gets dropped.

[FPC02] 2026-04-09 06:41:52.377316 GRE1_TEST_SY_U out 2.2.2.2 -> 4.4.4.4: icmp: echo request



[FPC02] 2026-04-09 06:41:52.877881 GRE1_TEST_SY_U out 2.2.2.2 -> 4.4.4.4: icmp: echo request

[FPC04] 2026-04-09 06:41:52.334265 GRE1_TEST_SY_U in 4.4.4.4 -> 2.2.2.2: icmp: echo reply

[FPC04] 2026-04-09 06:41:52.834796 GRE1_TEST_SY_U in 4.4.4.4 -> 2.2.2.2: icmp: echo reply

• In debug flow, no sessions are matched since FPC4 does not have the session, which is expected, since traffic egresses via FPC2.

[FPC02] id=20085 trace_id=1465 func=print_pkt_detail line=6430 msg="vd-root:0 src_slot:2 received a packet(proto=1, 2.2.2.2:8874->4.4.4.4:2048) from local. type=8, code=0, id=8874, seq=5380."



[FPC02] id=20085 trace_id=1465 func=resolve_ip_tuple_fast line=6541 msg="Find an existing session, id-00002d3d, original direction"

[FPC02] id=20085 trace_id=1465 func=fw_local_out_handler line=997 msg="local-out traffic"

[FPC04] id=20085 trace_id=466 func=print_pkt_detail line=6430 msg="vd-root:0 src_slot:4 received a packet(proto=1, 4.4.4.4:8874->2.2.2.2:0) from GRE1_TEST_SY_U. type=0, code=0, id=8874, seq=5380."

[FPC04] id=20085 trace_id=466 func=vf_ip_route_input_common line=2611 msg="find a route: flag=84000000 gw-2.2.2.2 via root"

[FPC04] id=20085 trace_id=466 func=ip_session_core_in line=7172 msg="no session matched"

• The trigger point of the issue is the flow rule:

    edit 22
        set status enable
        set ether-type ip
        set protocol gre
        set forward-slot FPC4
    next

Note:

Health check traffic is always forwarded through the master FPC (slot 2 in this case). However, due to flow rule 22, the return traffic is being redirected to slot 4.

Once flow rule 22 is disabled, the traffic correctly remains on slot 2 and functions as expected.

• Working packet capture:

[FPC02] 2026-04-09 06:47:16.641981 GRE1_TEST_SY_U out 2.2.2.2 -> 4.4.4.4: icmp: echo request



[FPC02] 2026-04-09 06:47:16.642241 GRE1_TEST_SY_U in 4.4.4.4 -> 2.2.2.2: icmp: echo reply

• Working debug flow:

[FPC02] id=20085 trace_id=1522 func=print_pkt_detail line=6430 msg="vd-root:0 src_slot:2 received a packet(proto=1, 2.2.2.2:8885->4.4.4.4:2048) from local. type=8, code=0, id=8885, seq=5436."



[FPC02] id=20085 trace_id=1522 func=resolve_ip_tuple_fast line=6541 msg="Find an existing session, id-00002da4, original direction"

[FPC02] id=20085 trace_id=1522 func=fw_local_out_handler line=997 msg="local-out traffic"

[FPC02] id=20085 trace_id=1523 func=print_pkt_detail line=6430 msg="vd-root:0 src_slot:2 received a packet(proto=1, 4.4.4.4:8885->2.2.2.2:0) from GRE1_TEST_SY_U. type=0, code=0, id=8885, seq=5436."

[FPC02] id=20085 trace_id=1523 func=resolve_ip_tuple_fast line=6541 msg="Find an existing session, id-00002da4, reply direction"

• The flow rule can be modified to send to the master FPC:

config load-balance flow-rule
    edit 22
        set status enable
        set ether-type ip
        set protocol gre
        set forward-slot master
    next
end