Technical Tip: How Policy Routes, Auxiliary Sessions, and Asymmetric Routing impact reply traffic handling (FortiOS v6.2, v6.4, and v7.0+)

[Anonymous]

Description	This article describes how reply traffic forwarded by the FortiGate (i.e., server traffic being forwarded back to the client) is impacted by policy-based routing, as well as auxiliary sessions and asymmetric routing.
Scope	FortiOS v6.4.0 through v6.4.9, FortiOS v6.4.10/v7.0.1 and later
Solution	As a primer, policy routes created on the FortiGate are typically created for the purposes of overriding the routing for outgoing traffic. For example, an admin might use a policy route to send traffic sourced from a specific client towards a different next-hop gateway/interface, rather than following the main routing table. However, policy routes can also affect the routing of reply traffic, which can be useful in cases where two different next-hop gateways can be used to reach a given remote network. Consider the following example topology: In the above topology, the Client (172.16.0.100) would send traffic towards the Server (10.0.0.100) via Router 1 (192.168.0.254), and reply traffic from the Server needs to be routed back towards the client using a different next-hop gateway than the one configured for the default route in the routing table. In FortiOS v6.2, the FortiGate automatically utilizes the policy route against the reply traffic, and so reply traffic from the Server would be routed towards the Client via Router 1. In FortiOS v6.4.0 through FortiOS v6.4.9, as well as FortiOS v7.0.0, the behavior was changed as per Change #608748, and so policy routes were no longer matched for reply traffic. In this case, reply traffic from the Server would instead be routed towards the Default Router (192.168.0.1) as per the main routing table, and so communication would be incomplete. Finally, in FortiOS v6.4.10, v7.0.1, and all later versions, the behavior was updated as per Change #718512 to the following: If auxiliary-route and asymroute are both disabled (default settings), then reply traffic will always be routed back out using the same interface it arrived on (e.g., Client traffic arrives on port1, Server reply traffic is forwarded back out port1 as well). The FortiGate then performs the following series of checks: If a policy route exists that also matches this incoming interface, then it will be utilized (e.g., Server reply traffic is forwarded out port1 towards Router 1 as the next-hop, as per the policy route). If no policy route exists that matches this incoming interface, then the regular routing table will be used instead (e.g., Server reply traffic follows the default route if the policy route is removed). Policy routes that use a different interface than the incoming interface will generally not be utilized unless the original incoming interface is removed for some reason (e.g., administratively shut down, route deleted, etc.). If either auxiliary-route or asymroute is enabled, then reply traffic will always be routed based on the first matching policy route (even if it specifies a different interface). Note that the auxiliary-route and asymroute settings are generally reserved for environments where asymmetric route flows are expected to occur. To learn more about what these settings affect when enabled, review the links in the Related Documents section below. Related documents: Controlling return path with auxiliary session Technical Tip: How the FortiGate behaves when asymmetric routing is enabled