About asymmetric routing features
Settings for asymmetric route detection are under Networking > Networking Integration: Asymmetric Routing.
This feature helps identify and manage situations where packets take different paths to and from a destination—something known as asymmetric routing. While this routing pattern is common in large networks, it can cause problems for devices like SteelHeads, firewalls, and VPNs, which need to see all traffic in both directions to work correctly.
SteelHeads must be placed so that all TCP traffic flows through the same appliances in both directions. If traffic only passes through SteelHeads in one direction, clients may fail to connect to servers.
When asymmetric route detection is enabled, client-side SteelHeads automatically detect asymmetry. If found, the SteelHead will bypass optimization for affected traffic to allow the connection to continue. The first connection between a pair of IP addresses might fail during detection, but once asymmetry is confirmed, all future connections between those hosts are passed through unoptimized. These conditions are stored in the asymmetric routing table and remain in effect until the entry times out. This feature also supports IPv6.
The Networking > Network Integration: Asymmetric Routing page displays the asymmetric routing table. The following table describes the different types of asymmetry.
Type | Description | Asymmetric routing table and log entries |
|---|
Complete Asymmetry | Packets traverse both SteelHeads going from the client to the server but bypass both SteelHeads on the return path. | • Asymmetric Routing Table: bad RST • Log: Sep 5 11:16:38 gen-sh102 kernel: [intercept.WARN] asymmetric routing between 10.11.111.19 and 10.11.25.23 detected (bad RST) |
Server-Side Asymmetry | Packets traverse both SteelHeads going from the client to the server but bypass the server-side SteelHead on the return path. | • Asymmetric Routing Table: bad SYN/ACK • Log: Sep 7 16:17:25 gen-sh102 kernel: [intercept.WARN] asymmetric routing between 10.11.25.23:5001 and 10.11.111.19:33261 detected (bad SYN/ACK) |
Client-Side Asymmetry | Packets traverse both SteelHeads going from the client to the server but bypass the client-side SteelHead on the return path. | • Asymmetric Routing Table: no SYN/ACK • Log: Sep 7 16:41:45 gen-sh102 kernel: [intercept.WARN] asymmetric routing between 10.11.111.19:33262 and 10.11.25.23:5001 detected (no SYN/ACK) |
multiSYN Retransmit | The types of multi-SYN retransmits are: • Probe-filtered occurs when the client-side SteelHead sends out multiple SYN+ frames and doesn’t get a response. • SYN-remit occurs when the client-side SteelHead receives multiple SYN retransmits from a client and doesn’t see a SYN/ACK packet from the destination server. | • Asymmetric Routing Table: probe-filtered (not-AR) • Log: Sep 13 20:59:16 gen-sh102 kernel: [intercept.WARN] it appears as though probes from 10.11.111.19 to 10.11.25.23 are being filtered. Passing through connections between these two hosts. |
Detecting and caching asymmetric routes doesn’t optimize these packets. If you want to optimize asymmetric routed packets, you must make sure that packets going to the WAN always go through a SteelHead either by using a multiport SteelHead, connection forwarding, or using external ways to redirect packets, such as WCCP or PBR.