A stateless subnet filter fronts a workload whose own rule set is stateful — what does each need written for return traffic?
answer
- two filters, two different machines
- who remembers the request
- the reply is a separate packet
- ephemeral port on the client side
- stateless needs the return direction too
basics
~20 sThe stateful rule set needs only the request direction written; it matches the reply to the flow it already accepted. The stateless subnet filter judges each packet alone, so the reply needs its own rule allowing the client's ephemeral port range.
solid answer
~40 sTwo boundaries, two different machines. A rule set attached to the workload is normally **stateful**: it decides on the first packet of a flow, records that flow, and matches every later packet — including the reply — against that record. You write the inbound allow and nothing else. A filter attached to the subnet is normally **stateless**: it has no record, so the reply is just another packet travelling outbound, from the service port to whatever high `ephemeral port` the client picked. If the outbound direction of that filter does not allow the ephemeral range back to the caller, the reply is dropped. The symptom is a hang rather than a refusal, because nothing rejects anything — the request is served and the answer vanishes at the subnet boundary.
go deeper
Remember the one-line difference: a stateful boundary needs the request direction written, a stateless one needs both directions. Recall that the reply goes to a high ephemeral port the client chose, not back to the service port.
Explain the mechanism, not the label: the first packet is decided against the rules and recorded, later packets of that flow are matched against the record. Then explain why a stateless layer cannot do that and what it forces you to write.
Show the diagnosis. Say why the symptom is a hang, why a test from inside the same subnet passes, and why the workload's own logs look healthy. Name the direction and destination port you would check at each boundary.
Frame it as a policy-placement standard: precise per-tier policy on the stateful workload layer, coarse whole-subnet statements on the stateless layer, so that return-traffic rules never have to be fine-grained and no team writes a broad ephemeral allow to make their tier work.
## Two filters that look alike and are not Inside a private address range you allocate on a provider's platform there are usually two places to filter traffic: a filter attached to a **subnet**, which every packet entering or leaving that subnet crosses, and a rule set attached to the **workload**, which only that workload's traffic crosses. On the platforms that offer both, the subnet-level filter is typically **stateless** and the workload-attached rule set is typically **stateful**. That property, not the scope, is what decides how much you have to write. ## What stateful means A stateful filter makes its decision on the **first packet of a flow** and records that flow — the two addresses, the two ports and the protocol — in a connection table. Every later packet belonging to that flow, in either direction, is matched against the table rather than decided again against the rules. So when you allow inbound traffic to the service port, the reply is allowed as a consequence: it belongs to a flow the filter already accepted. These rule sets are normally **allow-only with an implicit deny** — anything you have not allowed is refused, and there is nothing at all to write for return traffic. ## What stateless means A stateless filter keeps no connection table. Each packet is judged on its own, against an ordered list, in whichever direction it happens to be travelling. The reply to a request is a *separate packet in the opposite direction*: it leaves from the service port and is addressed to whatever **ephemeral port** the client's operating system picked for that connection, typically somewhere in the high range above 1024. The filter has no idea it is a reply. If the outbound direction does not allow that traffic, the reply is dropped. ## The reply, written out | Boundary | Inbound rule you write | Outbound rule you write | |---|---|---| | Stateful rule set on the workload | allow the service port from the caller | none — the tracked flow covers it | | Stateless filter on the subnet | allow the service port from the caller | allow the high ephemeral range back to the caller | The ephemeral range is chosen by the client, not by you, so a stateless return rule has to be broad enough to cover it. That is one reason the stateless layer is a coarse instrument and the workload-attached one carries the precise policy. ## Why this failure is mis-diagnosed - The symptom is a **hang, not a refusal**. The request arrives, the workload answers, and the answer disappears; the client sits until its own timeout fires. Nothing sends an error, so there is no error to read. - Testing **from inside the same subnet** succeeds, because that traffic never crosses the subnet boundary and so never meets the stateless filter at all. - The workload's own logs show the request **served successfully**, which sends people to the application, the route table or name resolution instead of to the return direction. - The mirror image fails identically: a call *initiated outbound* from the subnet needs the **inbound** direction of the stateless filter to allow the ephemeral range, and forgetting that looks like the dependency being down. The habit worth building is to ask, for every boundary a packet crosses, **in which direction** it is crossing and **which port is the destination** — and to check the return direction explicitly wherever the layer is stateless. ## Where each one belongs 1. Put the **workload-attached stateful rule set** at the centre of the design. It is where precise per-tier policy lives, it is safe by construction because it is allow-only, and it needs no return rules. 2. Use the **stateless subnet filter** as a coarse backstop for the whole subnet — a broad statement such as "nothing in this subnet reaches that range at all" — which survives a mistake in any single workload's rules. 3. Do not try to express fine-grained policy on the stateless layer. Every precise rule there doubles, because the return direction must be written too, and that return rule is necessarily broad. ## The trade underneath State costs memory and bookkeeping. A stateful filter holds an entry per flow, which is why very high connection counts and long-idle connections behave differently there. A stateless filter holds nothing, which makes it cheap, predictable and immediate — it applies to the very next packet, with no already-accepted flow to survive a change. Neither is safer in general. They fail in different directions, and knowing which of the two dropped a packet is most of the work of debugging a boundary.
- Why does the missing return rule show up as a hang instead of a connection refused?A refusal requires something to send a rejection back. A stateless filter that does not match an allow simply discards the packet, so the client never hears anything and waits out its own timeout. The workload, meanwhile, believes it answered successfully — which is why its logs look healthy while the caller reports an outage.
- The same missing rule breaks outbound calls too — which direction is wrong then?The inbound one. When the workload initiates the call, the reply arrives from outside addressed to the ephemeral port the workload chose, so the stateless filter's inbound direction must allow that high range. Teams usually write the outbound allow, see the request leave, and never check the return direction.
- If the stateful layer needs fewer rules, why keep a stateless subnet filter at all?Because it applies to everything in the subnet regardless of what any individual workload's rules say, so it survives a mistake made one tier down. It is also immediate — with no tracked flows, a change takes effect on the next packet. Keep it coarse: a whole-subnet statement, not per-tier policy.
A stateful filter is a doorman who remembers letting you in and waves you back out without asking. A stateless one checks a card at every doorway and needs the way out written down separately.
saying these in an interview costs you the question
- Says a stateful rule set still needs an explicit outbound allow for the reply
- Assumes both boundaries behave the same because both filter traffic
- Thinks allowing an inbound port implies the reply is allowed everywhere
- Writes the stateless return rule to the service port, not the ephemeral range
- Blames the application or the route when only the return direction is filtered