Staff

Troubleshooting Tip: Routing Changes and SNAT (snat-route-change)

Forum|Forum|8 years ago
January 4, 2018
1 reply
51582 views

Description

This article provides details about Routing Changes with existing SNAT sessions on a FortiGate.

When troubleshooting, if after a routing change (For instance, setting up a VPN with corresponding added routes) a session for a particular communication goes via the wrong interface and/or firewall policy, it is probably due to keepalive traffic. The result is that sessions do not expire, and by default, the FortiGate does not flush routing information for those sessions.

Scope

FortiGate.

Solution

Routing Changes without Source NAT (SNAT): After a routing change, routing information is flushed from the affected sessions where source NAT (SNAT) is not applied.

Routing lookups are done again for the next packets.
Route cache entries are removed.
RPF check is done again for the first packet in the original direction.
The session is flagged as dirty.

Example of a session just after a routing change:

The gateways in both directions change to 0.0.0.0/0 and the interfaces to 0, indicating that this information must be learned again. In addition, the dirty flag is added.

Routing Changes and SNAT (snat-route-change). In sessions where SNAT is applied, the action depends on the following setting (which is disabled by default):

   config system global
     set snat-route-change [disable|enable]
   end

When this setting is enabled, the routing information is flushed from the session table, just like it is when SNAT is not applied to a session.

During reevaluation of SNAT sessions, if the new route and firewall policy lookup results in a change of the SNAT IP Address, then FortiGate drops the packet and clears the session. This means that the impacted application could have to initiate a new connection to resume network connectivity, especially if the application is TCP-based.

id=20085 trace_id=51 func=print_pkt_detail line=5746 msg="vd-root:0 received a packet (proto=1, 10.0.1.101:13106->8.8.8.8:2048)"
id=20085 trace_id=51 func=resolve_ip_tuple_fast line=5827 msg="Find an existing session, id=00008483, original direction"
id=20085 trace_id=51 func=vf_ip_route_input_common line=2589 msg="Match policy routing id=2131230721: to 8.8.8.8 via ifindex=4"
id=20085 trace_id=51 func=vf_ip_route_input_common line=2615 msg="find a route: flag=04000000 gw=192.2.0.10 via port2"
id=20085 trace_id=51 func=get_new_addr line=1229 msg="find SNAT IP: 192.2.0.9 (from IPPOOL), port=13106"
id=20085 trace_id=51 func=fw_stc_dirty_session_check line=264 msg="SNAT IP 192.2.0.1 != 192.2.0.9, drop"

Above is an example of debug flow output of an SNAT session during reevaluation. Because the SNAT IP address of the new path (192.2.0.9) is different from the SNAT IP address of the current path (192.2.0.1), FortiGate drops the packet and clears the session.

Troubleshooting:

To flush the table, delete and add the new route again, or change it.

When this setting is disabled (by default), after a routing change, established sessions with SNAT keep using the same outbound interface, as long as the old route is still active, or they expire (even though the route is no longer the best).

To update routing information, those sessions must be cleared. See related articles.

Related articles:

Technical Tip: Using filters to clear sessions on a FortiGate unit

Troubleshooting Tip: FortiGate session table information

Technical Tip: Using 'SNAT-route-change' to update existing NAT session after routing change (e.g. after IPSEC tunnel is up)

FortiGate

nileshkahar

Explorer III

Today, we faced the issue after firewall reboot where in DHCP packets were going over Internet instead of VPN tunnel. As per support, this would have been the case as Internet comes online first & then VPN tunnel so that route table will build for internet for particular DHCP packet & not getting dropped until the session is flushed. Only after flusing the previously built session it started taking VPN route though the static route was always there.

As per me, this is very weird routing situation where firewall is not updating the route dynamically flushing the stale DHCP session in turn creating outage :-(

If above is the case, why Fortinet is not making this command “set snat-route-change enable” as default? I have now implemented this command to avoid such issue in future - is it going to hamper anything?

Is it going to create any issue if I enable this command for all the firewalls?

Sign up

Login with SSO

Login to the community

Login with SSO