Skip to main content
Jposada
Staff
Jposada
Staff
January 4, 2018

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

  • January 4, 2018
  • 0 replies
  • 50677 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

 
  1. 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:

jposada_tn_FD40943-1.jpg


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.

 

  1. 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)

Terms & ConditionsAccessibility statement