Description
This article describes the importance of the 'SLA-Stickiness' feature on an SD-WAN-enabled FortiGate, when it is mandatory, and why.
Failing to utilize the feature in some scenarios will cause unstable connections with constant traffic disruptions that will negatively affect any end-to-end TCP stream (session/connection).
Scope
SD-WAN, NAT, Sessions, FortiGate v7.4.5+.
Solution
Some common scenarios include traffic flows through an SSE/SASE provider via an IPSec and/or a GRE tunnel with NAT on the remote-end.
To read more about the SASE technology, such as FortiSASE, visit FortiSASE.
Whenever a session is initiated between a given source to a destination that traverses a FortiGate and is not being NATed, but instead involves NAT on any upstream device (another FortiGate or any 3rd party router/NAT device), rather than the FortiGate itself.
This issue is exacerbated if load-balancing is used in the SD-WAN rules (lowest cost + load balance).
With such a configuration, it is expected to have a frequently changing order of the preferred member for outgoing traffic, such as when the load balancing algorithm used ('hash-mode') is set to inbandwidth/outbandwidth/bibandwidth.
This is as opposed to the default round-robin.
To verify the order and amount of changes, use the commands:
diagnose sys sdwan service4
diagnose firewall proute list
diagnose sys vd list | grep ver
In such cases, there is nothing 'special' about those sessions that could instruct the FortiGate on exempting them from session re-evaluation.
By default, the global setting of 'snat-route-change' is disabled, and so is not an issue when SD-WAN sessions are NAT locally.
Additional details on that feature can be found in the article below:
Troubleshooting Tip: Routing Changes and SNAT (snat-route-change)
Consider the following network topology diagram examples below:
A session is initially established by member 1 towards any public destination.
If during the session's life it becomes 'dirty' and gets re-evaluated with member 2 as the new chosen egress interface, this will break the session on the remote (server) end, as it is the first packet seen from that source IP, the corresponding NAT device.
Resolving the issue with potential member flaps, i.e., existing sessions can move between members upon every session re-evaluation event (session/s flagged as 'dirty').
This can be achieved by using the 'SLA-Stickiness' feature.
Ensuring that in case of a session re-evaluation, even if an SD-WAN session is flagged 'dirty', it will not be subject to a new oif (outgoing interface) change and thus remain on the original member.
Provided that the current member/oif is alive & in-SLA, otherwise, the rule does not apply and the session WILL move to another member/interface.
The 'SLA-Stickiness' command was introduced in FortiOS v7.4.1 as a replacement & enhancement of the previous 'Shortcut-stickiness' feature that was only relevant for ADVPN shortcut IPSec tunnels.
The further expansion of this feature includes all SD-WAN members.
Following a behavior change of the internal route cache flushing mechanism (which is triggered on every FIB version change), starting from FortiOS v.7.4.5, the effect is a much more frequent and accurate session re-evaluation.
- Configure or make sure a specific SD-WAN rule exists, steering the relevant traffic appropriately.
- Validate the SD-WAN Performance SLA used in the lowest cost SLA + LB rule is stable with the correct thresholds that are not too aggressive (too low).
- Under the SD-WAN rule/s, configure the additional command 'set sla-stickiness enable'.
This ensures stable flows while avoiding constant TCP reset flags when source IP changes mid-session the as described above.
Verification:
diagnose firewall proute list
Check that the 'sla-stickiness' is present in the output as below:
id=2133524481(0x7f2b0001) vwl_service=1(Corporate-H1) vwl_mbr_seq=3 4 dscp_tag=0xfc 0xfc flags=0x410 load-balance hash-mode=inbandwidth sla-stickiness tos=0x00 tos_mask=0x00 protocol=0 port=src(0->0):dst(0->0) iif=0(any)
path(2): oif=17(HUB1-VPN1) num_pass=1in sla path_last_used=2025-11-17 05:26:36, oif=16(HUB1-VPN2) num_pass=1in sla
source(1): 10.0.0.0-10.255.255.255
destination(1): 10.0.0.0-10.255.255.255
hit_count=8938 rule_last_used=2025-11-17 05:26:36
diagnose sys sdwan service4
Check that the 'sla-stickiness' is present in the output as below:
Service(1): Address Mode(IPV4) flags=0x2c200 use-shortcut-sla use-shortcut sla-stickiness
Tie break: cfg
Shortcut priority: 2
Gen(1), TOS(0x0/0x0), Protocol(0): src(1->65535):dst(1->65535), Mode(sla hash-mode=inbandwidth)
Members(2):
1: Seq_num(3 HUB1-VPN1 overlay), alive, sla(0x1), gid(2), num of pass(1), inbandwidth: 9999999Kbps, selected
2: Seq_num(4 HUB1-VPN2 overlay), alive, sla(0x1), gid(2), num of pass(1), inbandwidth: 9999999Kbps, selected
Src address(1):
10.0.0.0-10.255.255.255
Dst address(1):
10.0.0.0-10.255.255.255
Additional documentation about the feature and design use cases can be found here:
