2026-06-03

Asymmetric Routing and One-Sided PCAP Analysis

How to analyze asymmetric routing and one-sided packet captures, missing replies, NAT/firewall paths, half conversations, capture point mistakes, and misleading retransmission evidence.

A one-sided PCAP full of SYN or data retransmissions can look exactly like a firewall drop even when replies travel through another interface, NAT leg, or asymmetric route. Validate the capture point before diagnosing loss: compare endpoint counters, routing, MAC addresses, TTLs, NAT translations, and a second vantage point for the missing SYN-ACK or ACK stream. The original trace proves that replies were not visible there; it does not prove that no reply existed anywhere on the network.

PCAP Surgery is useful because one-sided captures need careful trimming, labeling, and comparison. You must preserve enough context to prove whether packets are absent from the network or absent only from that capture point.

What asymmetric routing means

Asymmetric routing means request traffic and response traffic take different network paths. This can be normal in complex networks, but it confuses analysis if you capture at only one point.

Example:

client -> firewall A -> server
server -> firewall B -> client

A capture on firewall A may show client requests and no server replies. That does not automatically mean the server failed to respond.

One-sided capture symptoms

Common trace patterns:

SYN retransmissions with no SYN-ACK.
HTTP request visible but no HTTP response.
DNS query visible but no answer.
TLS ClientHello visible but no ServerHello.
ACKs appear without the data they acknowledge.
Retransmissions look excessive.
Sequence analysis seems impossible.
Firewall logs disagree with pcap.

These symptoms can indicate packet loss, but they can also indicate capture placement.

Missing SYN-ACK

If a client sends SYN and you never see SYN-ACK, possibilities include:

Server never received SYN.
Server replied through another path.
Firewall dropped SYN-ACK.
NAT state is missing.
Capture interface sees only egress traffic.
Switch SPAN is configured for one direction.
Cloud mirror session misses return traffic.

The next step is not to assume server failure. Capture closer to the server or on the return path.

NAT and address rewriting

NAT makes one-sided analysis harder because the same flow may have different addresses on each side of a firewall or load balancer.

Questions:

What is the pre-NAT tuple?
What is the post-NAT tuple?
Is source NAT or destination NAT used?
Does return traffic match existing state?
Does the capture occur before or after translation?
Are multiple clients sharing one translated address?

PCAP Surgery can help keep separate conversations and annotate which side of NAT each capture represents.

Firewall state and asymmetric paths

Stateful firewalls expect return traffic to pass through the same state table. If request and response paths differ, the return packet may be dropped as out-of-state.

Evidence:

SYN visible on one firewall.
SYN-ACK visible on a different firewall.
Return path firewall logs state violation.
Client retransmits SYN.
Server believes it responded.

This is a routing and firewall design issue, not a TCP stack bug.

SPAN and mirror mistakes

Packet captures from switches, cloud mirrors, or hypervisors can be incomplete.

Common mistakes:

Mirror only ingress traffic.
Mirror only egress traffic.
Capture wrong VLAN.
Capture after offload has changed packet shape.
Capture on bridge interface but not physical interface.
Container or VM path bypasses expected interface.
Cloud traffic mirroring samples or truncates traffic.

Before diagnosing packet loss, verify capture scope.

Misleading retransmission evidence

If you see many retransmissions in a one-sided capture, the sender is not receiving ACKs on the path you observe. But that does not prove the receiver never sent ACKs.

Compare:

Sender-side capture.
Receiver-side capture.
Firewall ingress and egress captures.
Load balancer frontend and backend captures.
NAT before and after captures.

Two small pcaps at the right points are often better than one large pcap at the wrong point.

How to write a useful report

For asymmetric routing analysis, include:

Capture point name.
Interface direction.
VLAN or tunnel context.
Pre-NAT and post-NAT addresses.
Flow tuple.
First missing packet.
Whether the opposite direction appears anywhere.
Firewall or load balancer path.
Time synchronization between captures.

Without capture point metadata, the pcap can be misleading.

Debug checklist

Use this workflow:

Identify the exact flow tuple.
Mark the capture point.
Confirm whether both directions are expected there.
Look for missing first reply.
Check NAT translation.
Compare firewall state.
Capture near client and server.
Capture before and after load balancer if present.
Align timestamps between pcaps.
Preserve enough packets to prove path asymmetry.

Final diagnosis

Asymmetric routing and one-sided captures can make normal replies look missing. The important evidence is capture placement, direction, NAT state, firewall path, and whether the missing packets appear at another point.

PCAP Surgery helps engineers trim, preserve, and compare the right packet evidence so "missing replies" becomes a routing, NAT, firewall, or capture-scope diagnosis instead of a misleading packet-loss claim.

Prove capture visibility before proving a drop

Start with traffic that should definitely be bidirectional at the sensor: ARP/neighbor discovery, a known healthy TCP flow, or mirrored interface counters. Confirm SPAN direction, VLAN coverage, bonding member, namespace, virtual switch, and capture filter. A sensor that sees only transmit traffic will produce convincing but false “all replies dropped” stories.

Visibility check	What failure suggests
Healthy flow also shows one direction	Capture/SPAN/filter problem
Return packets appear on another interface	Asymmetric route or bonding path
Server sees request and sends reply	Loss/visibility lies after server point
Client receives reply absent from middle trace	Middle sensor missed return direction
NAT tuple changes between points	Correlation must use translated identities

Capture-point metadata should include device, interface, VLAN, tap/SPAN method, pre/post-NAT position, direction, timestamp source, packet-drop counters, and whether hardware offload is active. “Firewall capture” is not precise enough when the platform has ingress, egress, virtual, and accelerated paths.

How do you correlate flows across NAT?

Use logs or simultaneous captures to map original and translated addresses/ports. Correlate protocol timing, sequence numbers, TCP timestamp options, payload lengths, and unique application identifiers. Do not filter both files using only the pre-NAT tuple.

Can TTL prove asymmetric routing?

TTL/hop-limit differences can support a path change, but endpoints choose different initial values and middleboxes may rewrite traffic. Compare repeated packets from the same endpoint and direction, alongside routing and interface evidence.

Why can a firewall allow one direction but lose state?

Stateful devices may see only half of an asymmetric connection, reject return traffic on another node, or apply reverse-path filtering. Packet evidence must be paired with state tables, HA ownership, route lookup, and policy counters at the relevant time.

Multi-point capture method

Place sensors near client and server, and on both sides of the suspected middlebox when authorized. Synchronize clocks or align the same unique packets. Record capture drops. Build a per-packet presence table:

Packet	Client edge	Firewall ingress	Firewall egress	Server edge
SYN	yes	yes	yes	yes
SYN-ACK	yes	no	no	yes

This example proves the SYN-ACK existed at the server and client but was not visible at the firewall sensors; it points to capture scope or an alternate return path, not a firewall drop between those two interfaces.

Actionable final report

State the exact observer and absence: “At firewall-A ingress, client SYNs were visible; no SYN-ACKs for the translated tuple were observed. Server-edge and client-edge captures both observed the SYN-ACK, supporting a return path that bypassed firewall A.” Include route lookup, NAT mapping, interface counters, and clock uncertainty.

Retain handshakes from normal and affected flows, translation context, and matching packets across sensors. Use capture scope help and the complete evidence workflow before creating a shareable derivative.

What if only one capture is available?

Conclude only what that point saw. Ask for endpoint socket logs, firewall counters, route tables, NAT state, and a replacement multi-point capture. Do not convert “reply absent here” into “server never replied.”

Common virtual and cloud capture traps

Cloud mirrors, hypervisor taps, containers, service meshes, and accelerated datapaths can expose traffic at unexpected stages. A pod capture may show the application leg but not node-level NAT. A host interface may miss hardware-offloaded traffic. A load balancer creates separate client and backend conversations. Record the logical and physical observation boundary.

Environment	Missing context to check
Container/pod	namespace, veth peer, node NAT, sidecar
VM host	bridge, tap, physical NIC, offload
Cloud traffic mirror	selected ENI, direction, filter, truncation
Load balancer	frontend versus backend TCP leg
Firewall cluster	active node, HA state, asymmetric member

Capture a known request with a unique time or correlation value and trace it through the layers. This validates the observation model before an outage interpretation is built on it.

Can asymmetric routing be normal?

Yes. Large networks may intentionally use ECMP or distinct ingress/egress paths. It becomes operationally relevant when stateful policy, NAT ownership, reverse-path filtering, monitoring, or troubleshooting assumes symmetry.

How should the fix be validated?

Repeat the route and state test under normal and failover conditions. Confirm both directions appear at every device that requires state, NAT translations remain stable, and endpoint behavior succeeds. Preserve before/after route outputs, counters, and representative handshakes.

The goal is not necessarily to force symmetry; it is to make routing, state ownership, and visibility compatible and documented.

Minimal escalation package

Include network diagram, client/server and translated tuples, capture-point labels, route lookups in both directions, NAT/state-table owner, first missing packet, matching packet from another observer, interface/drop counters, and clock alignment method. Attach one healthy control flow using the same path assumptions.

Ask the routing owner to explain the expected forward and return next hops at the incident time, the firewall owner to confirm which node held state, and the platform owner to confirm mirror/tap coverage. This division prevents every team from receiving the same vague “packets missing” ticket.

A concise conclusion should distinguish visibility from forwarding: “The return packet was observed at server and client but not at sensor X; alternate routing or sensor coverage remains the lead.” That statement is stronger and safer than claiming a device dropped traffic without observing both sides of that device.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: