Quick Summary
- Asymmetric routing means the forward and return paths of a connection take different routes through the network
- Stateful firewalls track connections -- if return traffic arrives on a different path, the firewall has no record and drops it
- Fix by ensuring symmetric routes, using policy-based routing, or configuring firewall state synchronization
What is Asymmetric Routing?
In a perfectly symmetric network, a packet from Host A to Host B follows the same path as the reply from Host B back to Host A, just in reverse. But networks are rarely perfect. When the forward path and the return path differ, that is asymmetric routing. By itself, asymmetric routing is not a problem -- IP was designed to work with it. Each packet is routed independently based on the destination address, with no requirement that replies follow the same path.
The problem arises when a stateful device sits on only one of the two paths. A stateful firewall, a NAT gateway, or a load balancer tracks connections by remembering the initial request (the SYN packet in TCP). When the reply comes back on a different path, bypassing the stateful device, that device never sees the reply. If a new packet arrives that appears to be part of a connection the firewall never saw begin, it treats it as suspicious and drops it. The result: the connection hangs or times out, even though both the sender and receiver are working correctly.
Asymmetric routing is especially common in networks with multiple internet connections (multi-homed networks), redundant firewalls, or complex internal routing with multiple paths between subnets. It is one of the most frustrating problems to diagnose because all the individual components appear to be working -- the issue only manifests when you examine the full round-trip path.
Interactive: Forward vs. Return Path
Toggle the switch to fix symmetric routing. Watch how the return path changes.
Why Stateful Firewalls Care About Symmetry
A stateful firewall does not evaluate each packet in isolation. Instead, it maintains a connection table (also called a state table) that tracks every active connection. When a client sends a TCP SYN to a server, the firewall creates an entry: source IP, source port, destination IP, destination port, protocol, and the connection state (SYN_SENT). When the SYN-ACK reply comes back, the firewall matches it against the table, confirms it is a valid response, updates the state to ESTABLISHED, and forwards the packet.
But what if the SYN-ACK arrives on a different interface, or through a different firewall entirely? The firewall on the return path has no entry in its connection table for this flow. It sees what looks like an unsolicited SYN-ACK packet -- a potential attack. By default, stateful firewalls drop packets that do not match an existing connection. This is correct security behavior, but it breaks legitimate traffic when routing is asymmetric.
The same issue affects NAT gateways. When a client behind NAT sends a request, the NAT device records the translation (private IP:port mapped to public IP:port). The reply must come back through the same NAT device so it can reverse the translation. If the reply takes a different path, there is no NAT mapping, and the packet is dropped or misrouted.
How Asymmetric Routing Develops
Multi-Homed Networks
Organizations with two ISP connections often have asymmetric routing by default. Outbound traffic leaves through ISP-A based on routing policy, but the reply comes back through ISP-B because the remote server's routing tables prefer ISP-B's path. Each ISP connection typically has its own firewall or NAT, creating a state mismatch.
Redundant Firewalls Without State Sync
Two firewalls in an active-active configuration without connection state synchronization. The forward path goes through Firewall A, the return path through Firewall B. Firewall B has no record of the connection and drops the return traffic. Active-passive failover pairs can also cause this during failover if state is not replicated.
Unequal Cost Paths
OSPF or EIGRP may calculate different best paths from different directions. Router A's shortest path to Router B might go through Switch X, but Router B's shortest path to Router A goes through Switch Y. If a firewall sits on only one of these paths, traffic in one direction is inspected while the other direction bypasses inspection entirely.
Hot Potato Routing on the Internet
ISPs use "hot potato" routing -- they hand off traffic to the next network as quickly as possible, at the nearest peering point. But the return traffic from the other network may enter at a completely different peering point. This is normal on the internet and generally harmless, but it causes problems when enterprise firewalls sit at the boundary.
Fixing Asymmetric Routing
The most reliable fix is to make the routing symmetric -- ensuring that return traffic follows the same path as
the forward traffic. Policy-based routing (PBR) can force return traffic through the correct
firewall by matching on source address and overriding the routing table's decision. On Linux, this is done with
ip rule and multiple routing tables. On Cisco, use route-map with set ip next-hop.
For multi-homed networks, source-based routing is essential. Traffic that arrives on ISP-A's interface must leave through ISP-A, and traffic from ISP-B must leave through ISP-B. This prevents the reply from taking a different exit than the request's entry point. Most enterprise routers and Linux systems support this with multiple routing tables.
If asymmetric routing cannot be avoided, you can configure firewall state synchronization between redundant firewalls. Products like Palo Alto, Fortinet, and pfSense support syncing connection tables between firewall pairs, so both firewalls know about every connection regardless of which one saw the initial SYN. However, state sync adds complexity, latency, and potential failure modes.
Another option is to configure the firewall in stateless mode for specific traffic flows where asymmetry is unavoidable. This trades security (no connection tracking) for functionality. Use this sparingly and only for well-understood traffic patterns.
Real-World Scenarios
Dual-WAN Home Router
A home router with both a wired ISP and a 5G backup. Outbound traffic goes through the wired connection, but the 5G link has a lower-cost return path from the server's perspective. The NAT state exists only on the wired interface.
Data Center Active-Active Firewalls
Two firewalls load-balancing inbound traffic. A client's request arrives at FW-1, but the server's reply is hashed to FW-2 by the load balancer. Without state sync, FW-2 drops the reply.
Cloud Hybrid Networks
Traffic from on-premises to cloud goes through a VPN tunnel, but return traffic from the cloud uses a direct internet path because of a misconfigured cloud route table. The on-premises firewall drops the return traffic.
Diagnosing Asymmetric Routing
The classic diagnostic approach uses traceroute in both directions. Run traceroute from Host A to Host B,
then from Host B to Host A. If the paths differ significantly (different routers, different subnets), you have
asymmetric routing. On Linux, mtr provides a continuous traceroute that helps identify intermittent
asymmetry.
On the firewall itself, look for dropped packets in the logs with reasons like "no matching connection" or "invalid state." Check the connection table to see if the forward direction has entries but the return direction does not. Packet captures on both firewall interfaces (or on the alternative path) will confirm whether return traffic is taking a different route.
Common Mistakes
Disabling the Firewall Instead of Fixing Routing
When asymmetric routing causes drops, the temptation is to turn off stateful inspection. This fixes connectivity but removes all connection-level security. Always fix the routing instead.
Ignoring Source-Based Routing on Multi-Homed Hosts
A server with two network interfaces will reply on whichever interface the routing table says is best, not necessarily the interface the request arrived on. Without source-based routing, replies go out the wrong interface.
State Sync Without Testing Failover
Configuring state synchronization between firewalls but never testing an actual failover. Sync can silently stop working, and you will only discover it when a firewall fails and all existing connections are dropped.
Frequently asked questions about asymmetric routing
What is asymmetric routing?
Asymmetric routing happens when packets between two hosts take different paths in each direction — for example, traffic from A to B goes through router 1, but B's reply to A returns via router 2. The endpoints still see the conversation, but middleboxes along one of the paths may not.
Why do stateful firewalls drop asymmetric traffic?
A stateful firewall only allows return packets that match an existing connection in its state table. If the return path skips the firewall, the firewall never sees the original SYN — so when the SYN/ACK arrives from the other direction it has no matching state and gets dropped as out of state.
How do you fix asymmetric routing?
The clean fix is to make routing symmetric: use the same egress and ingress path for a given flow, often via policy-based routing, route metrics, or VRRP groupings. Alternatively, you can deploy a firewall cluster that shares state across both paths, or move to a stateless ACL where asymmetry is harmless.
Is asymmetric routing always bad?
No. Asymmetric routing is normal in ISP networks where BGP hot-potato routing intentionally takes different paths for different prefixes. It only becomes a problem when a stateful device, NAT, or per-flow QoS sits on one of the paths and not the other.
How do I detect asymmetric routing?
Run traceroute in both directions between the two hosts and compare hops. If the forward and reverse paths visit different routers or interfaces, traffic is asymmetric. Firewall logs showing out of state or invalid TCP flag drops are another strong signal.
Try asymmetric routing yourself
You just learned why stateful firewalls drop asymmetric flows. Now reproduce it: trace an HTTP connection whose request and reply take different paths, see the firewall drop the reply it has no record of, then change a route so both directions pass the firewall.
Launch the asymmetric routing lab →