IP forwards every packet independently; why can a connection's replies return by a different path, and what breaks when a stateful firewall sees only one direction?
answer
- no connections inside the network
- two lookups, two different keys
- each router decides alone
- state wants both directions
basics
~20 sRequests are routed by lookups of the server's address and replies by lookups of the client's, often in different routers, so paths can differ; a stateful firewall seeing one direction lacks half the connection and typically drops it.
solid answer
~50 sRFC 791 treats each datagram as "an independent entity" with "no connections or logical circuits", so routers keep a routing table, not a connection table. The request's path is chosen hop by hop by lookups of the **server's** address; the reply's path by lookups of the **client's** address, often by other routers applying other policies. **Asymmetric paths** are therefore normal and harmless to IP and to TCP's endpoints. They break anything that keeps per-flow state in the middle: a **stateful firewall** that sees the client's SYN but not the server's SYN-ACK typically treats the client's later packets as invalid and drops them; a NAT that sees one direction cannot translate the other; and RFC 1812's strict source-address validation discards valid packets arriving on the "wrong" interface. The fix is to make both directions cross the same stateful device, not to make IP remember flows.
go deeper
Recall that IP keeps no connections: each packet is routed alone, so a reply need not retrace the request's path.
Explain that the request is routed by the server's address and the reply by the client's, by different routers, and why that is normal.
Diagnose flows that stall after the handshake by finding the stateful device that sees one direction, and fix the topology rather than the routers.
Weigh where to place stateful devices against routing freedom: forcing symmetry limits path choice, while sharing state across devices costs complexity.
## What "stateless" means for IP RFC 791 says the Internet Protocol "treats each internet datagram as an independent entity unrelated to any other internet datagram. There are no connections or logical circuits (virtual or otherwise)." A router therefore holds a **routing table**, which is knowledge about destinations, and no **flow table** about conversations. Each packet is decided by a longest-prefix lookup of its own destination address. Implementations cache lookup results or precompute hardware forwarding tables, sometimes keyed per destination and sometimes per flow, but a cache only reproduces the answer the routing table would give. Forwarding does not depend on remembering which packets belonged to which connection. ## Why paths come out asymmetric 1. A client at `192.0.2.10` sends a request to a server at `10.1.1.7`. Every router on the way looks up `10.1.1.7`. 2. The server replies. Every router on the way back looks up `192.0.2.10`, a different prefix, often in different routers. 3. No router consults the request's path, because none recorded it. Asymmetry follows from ordinary decisions: - Two networks each send traffic for the other out of their **nearest** exit, so a request enters by one link and the reply leaves by another. - A site with **two edge routers** receives inbound traffic on one, while its internal routes send outbound traffic to the other. - A routing change mid-connection moves one direction but not the other. | Direction | Lookup key | Path in the two-edge example | |---|---|---| | Request | server `10.1.1.7` | upstream, edge router E1, firewall F1, server | | Reply | client `192.0.2.10` | server, edge router E2, firewall F2, upstream | ## What depends on symmetry IP and the TCP endpoints do not need symmetric paths: each end sees its segments arrive and measures round-trip time over both directions. The trouble is **state in the middle**: | Mechanism | What it needs | Failure on an asymmetric path | |---|---|---| | Stateful firewall | to see both directions of a connection | F1 sees the SYN, never the SYN-ACK; F2 sees a SYN-ACK with no SYN; a typical policy drops traffic that matches no tracked connection, so the connection stalls | | NAT | the reply to return through the device that made the mapping | replies reach a device that holds no mapping for them | | Strict source-address validation (RFC 1812 section 5.3.8) | each source to arrive on the interface the router would use to reach it | valid packets are silently discarded | Note what does not break: a stateless packet filter that judges each packet only by its own headers, and every router along either path. The failure appears only where a device must match a packet against something it saw earlier. RFC 1812 is explicit about the last one: a router **SHOULD** offer source-address validation, but if it does, the feature **MUST** be disabled by default, because it "can erroneously discard valid packets in situations where paths are asymmetric". ## Design responses - **Converge both directions on the stateful device.** Place the firewall or NAT where all paths for the protected network meet, or make the routing at that boundary symmetric. - **Pair state across devices.** Two stateful devices on two paths can share connection state, so either one recognises the flow. - **Use looser validation where paths diverge.** Many implementations offer a check that only requires some route to the source to exist, not one through the arrival interface; it tolerates asymmetry while still discarding unroutable sources. - **Do not ask IP to remember.** Making routers track flows would discard the property that lets them reroute instantly and scale to any number of conversations. ## How to reason about a symptom - Connections that open only sometimes, or stall after the handshake, while plain request-and-reply probes succeed, suggest a stateful device seeing one direction. - Ask which device makes the forward decision and which makes the return decision; they are rarely the same router. - Check whether the failure follows the topology: if only clients whose replies leave by the second exit are affected, the stateful device on the first exit is the suspect. - Remember that changing one router's table can move one direction of every flow through it, without touching the other direction.
- If IP is stateless, why can a router's forwarding look as if it remembered flows?Implementations cache lookup results or precompute hardware forwarding tables to go faster, but whatever key a cache uses, it only reproduces the routing table's answer; it is not connection state the forwarding depends on. Any per-flow consistency comes from deterministic rules on header fields, not memory. Change the routing table and the next packet of an existing connection follows the new answer.
- Why does RFC 1812 require strict source-address validation to be disabled by default?When enabled, it silently discards a packet whose source address the router would not route back out the interface the packet arrived on. On an asymmetric path, legitimate packets regularly arrive on such an interface. RFC 1812 section 5.3.8 says routers SHOULD implement the check but MUST ship it disabled, because it can erroneously discard valid packets where paths are asymmetric.
saying these in an interview costs you the question
- Replies always return along the reverse of the request's path.
- Routers keep a table of active connections to send replies back correctly.
- Asymmetric routing breaks TCP itself, even with no stateful device on the path.
- Strict source-address validation is safe to enable on any interface.
- A packet's path is fixed once the connection's first packet is routed.