Monkey Bites – SNAT Route Change

Monkey Bites are bite-sized, high-impact security insights designed for the busy professional. These rapid-fire posts skip the fluff to deliver immediate technical solutions, essential “gotchas,” and efficient lab hacks. Perfect for a quick read, they provide the exact signal you need without the noise of a full-length article.

If you’ve ever updated a static route or established a new VPN tunnel on a FortiGate, only to find that some traffic is still stubbornly clinging to the old, “wrong” interface, you aren’t alone. This is a common troubleshooting scenario that often boils down to how the FortiGate handles existing sessions during a routing change—specifically when Source NAT (SNAT) is involved.

In this post, we’ll explore why sessions sometimes fail to migrate to new routes and how the snat-route-change setting can help you regain control.

The Default Behavior: Why Sessions Stick

Under normal circumstances, when a routing change occurs on a FortiGate, the firewall “dirties” the affected sessions. This forces a re-evaluation of the routing table for the next packet in that session.

However, Source NAT (SNAT) changes the game. By default, FortiGate is designed to maintain the continuity of an SNAT session. If a session is already established with a specific NAT IP, the FortiGate will continue to use the original outbound interface as long as that route is still valid or until the session expires.

The Problem: If you have “keepalive” traffic (like a persistent database connection or a long-lived TCP stream), the session might never expire. It will keep using the old path even if a better route is now available.

The Solution: snat-route-change

To force the FortiGate to re-evaluate SNAT sessions immediately after a routing change, you need to toggle a specific global setting. When enabled, the FortiGate will flush the routing information from the session table and perform a fresh lookup.

What happens when you enable this?

config system global

          set snat-route-change enable

end

When snat-route-change is enabled, the FortiGate performs a new route and policy lookup for the next packet in an existing SNAT session.

1. If the route changes but the SNAT IP remains the same: The session is updated to the new interface, and traffic continues seamlessly.

2. If the SNAT IP must change: (For example, if the new path uses a different IP pool or outgoing interface IP). In this case, the FortiGate will drop the packet and clear the session.

While a “dropped packet” sounds bad, it is often necessary. A TCP session cannot survive a change in its Source IP address mid-stream; the destination server would see it as an invalid packet. By clearing the session, the FortiGate forces the application to initiate a new connection, which will then correctly follow the new route with the correct SNAT IP.

Troubleshooting & Best Practices

If you find that traffic is still stuck even after enabling this setting, or if you prefer not to change global settings, here are a few tips:

• Manually Clear Sessions: If only a few sessions are stuck, you can manually clear them using the CLI: diag sys session filter dport 443 (Example filter) diag sys session clear

• Check the “Dirty” Flag: Use diag sys session list to see if your sessions are marked as “dirty.” A dirty session is one that the FortiGate knows it needs to re-evaluate.

• Monitor Debug Flow: If you aren’t sure why a packet is being dropped, use the debug flow tool. You might see an error message like: SNAT IP 198.18.0.1 != 192.18.0.9, drop This confirms that the snat-route-change logic is working and clearing the session because the NAT IP no longer matches the new path.

The snat-route-change setting is a powerful tool for network administrators managing dynamic environments. While disabled by default to prioritize session stability, enabling it ensures that your FortiGate remains agile, moving traffic to the most optimal routes as soon as they become available.