Asymmetric routing can break a connection when its outgoing and returning packets cross different stateful firewalls. The second firewall may receive a reply without the connection record needed to accept it. Trace both directions of the affected connection, then correct the route or use a documented design that preserves the required inspection across devices.
When an application times out after a network change, check where its replies go before widening access. An allow rule describes permitted traffic; it does not supply another firewall with the history of a connection.
Follow the connection that never finishes opening
Consider a hypothetical wholesaler whose office staff use an order application on a separate server network. A routing change sends requests through firewall A and replies through firewall B. Both appliances are running. Assume they are independent stateful firewalls, do not share connection state, and perform no address translation on this particular path.
Request path: office computer → firewall A → order server.
Reply path: order server → firewall B → office computer.
Transmission Control Protocol (TCP) normally opens a connection through a three-way handshake: a synchronization request, a synchronization response with an acknowledgment, and a final acknowledgment. These packets are commonly labeled SYN, SYN-ACK, and ACK. The IETF TCP specification describes that exchange.
- The office computer sends SYN. Firewall A permits the new connection, creates its state record, and forwards the request to the order server.
- The server sends SYN-ACK. Its effective return route leads to firewall B. That firewall did not see the opening request and, under the assumed inspection behavior, drops the reply because it has no matching state.
- The computer waits for the reply. It cannot send the expected final acknowledgment. The order application eventually reports a connection timeout.
Cisco's explanation of asymmetric routing and connection state documents this failure pattern for its ASA firewalls. Actual behavior depends on the deployed platform, operating mode, and configuration.
The useful evidence is now specific. Firewall A sees the opening request; the server receives it and sends a reply; firewall B receives that reply and records a state-related drop. Together, those observations explain why the application cannot connect. If A simply has no reply in its logs, the next task is to locate the reply rather than assume B dropped it.
Find where the two directions separate
Ask the authorized network operator to follow one controlled connection attempt at a known time. Match the source and destination addresses, ports, and protocol across the client, gateways, and server. Where network address translation (NAT) is present, include the translated addresses and ports so the same connection remains identifiable on each side.
Use available connection records, drop reasons, effective route information, and appropriately scoped packet captures. Limit captures to the agreed systems and diagnostic need; avoid collecting application contents when packet headers are sufficient.
Different observations lead to different next steps. If the request never reaches the server, investigate the forward path first. If the server receives the request but sends no response, investigate the server and its local controls. If the server replies and the response reaches a different firewall, inspect that device's state and drop evidence before blaming the application.
Asymmetry can also occur when a reply bypasses a firewall entirely. Netgate's static-routing documentation illustrates an internal router returning traffic directly to a client while the outbound direction passes through the firewall. The inspection problem is incomplete visibility of the connection, even though the topology differs from the two-firewall example.
Network Box USA's Managed Unified Threat Management (UTM+) service combines stateful inspection, routing, NAT, traffic policy, logging, and managed operational support. Its deployment process includes validating traffic and telemetry and testing policy behavior. For traffic crossing the agreed managed gateway, the useful outcome is a working application path with its access policy and inspection preserved. The network and application teams can compare their evidence to identify which owner needs to change the route.
Correct the route with the security requirement intact
In the hypothetical wholesaler's network, suppose the operator confirms that the server network's route to the office subnet now selects firewall B. The proposed correction is to return that traffic through firewall A, where the connection is tracked. Review the actual route selection and dependencies before changing it; the appropriate fix might be on the server, a router, or a routing policy.
Keep the change as narrow as the verified cause permits. Moving an entire default route could affect unrelated services. Record which destination network needs the corrected path, who controls that route, and how to restore the previous configuration if the agreed test fails.
If the network intentionally uses different firewall nodes in each direction, have the supplier validate the supported architecture for that mode and software version. Establish how the design supplies the state and inspection needed for both directions. Two devices with identical access rules are insufficient evidence of that behavior.
Be explicit about any proposal to bypass state checks. Cisco's cited documentation says its TCP state-bypass mode omits application inspection and TCP normalization, among other limitations. That is a Cisco-specific example of a real tradeoff, not a statement that Network Box USA offers the same setting. Restoring connectivity by reducing inspection changes the security design and requires a separate decision.
Close the issue with a completed transaction
After the approved correction, start a fresh connection and verify that the wholesaler's order lookup completes. Confirm the expected packet path, required inspection, and continued enforcement of an agreed blocked flow. Retain the before-and-after evidence with the route change.
If the issue occurs during gateway takeover, use our firewall failover guide for the additional question of whether existing sessions survive. If connections open normally but transactions remain slow, our application-path measurement guide addresses delay and loss rather than this missing-handshake failure.
The managed gateway operator handles the agreed gateway scope; server routes, upstream networks, and application behavior require their respective owners. To discuss a persistent connection failure, contact our team with the affected workflow, a high-level path diagram, and the network change that preceded it. Arrange sensitive logs or captures through an agreed secure channel.