skip to content

A workload holds a public address and the filter permits the traffic, yet outside connections just hang — which route is missing?

level: middleimportance: must knowfreq 58%

answer

  1. an address is not a path
  2. check the reply, not the request
  3. outbound packets obey the subnet table
  4. no matching prefix means dropped inside
  5. hang points at a missing return path

basics

~20 s

The subnet's route table has no default route toward the network's internet-facing attachment, so the workload's reply has no path back out. A public address is an attribute; only a route makes it reachable, and the caller sees a hang.

solid answer

~40 s

Assigning a public address does not create a path. The inbound packet can still arrive, because the platform knows which workload owns that address and delivers it inward; the reply, however, is an ordinary outbound packet and obeys the route table associated with that subnet. If that table has only the route covering the network's own range, the reply matches nothing, is discarded inside your network, and the caller waits for a handshake that never completes. The fix is an entry covering all other destinations whose target is the network's internet-facing attachment. Note what the symptom tells you: a hang means the path is broken or something dropped silently, whereas an immediate refusal usually means the packet arrived and nothing was listening.

go deeper

for a junior

Recall that a public address makes a workload addressable but not reachable, and that the subnet's route table is what actually carries traffic in and out.

for a middle

Explain the asymmetry: the inbound packet is delivered by the network's internet-facing attachment, while the reply is an ordinary outbound packet matched against the subnet's table. Say why the symptom is a hang.

for a senior

Demonstrate the diagnosis order — prove the request arrived, then attack the return leg — and flag that adding the route changes the whole subnet, not one workload.

for a principal

Set the standard that reachability is a subnet-level design decision with its own blast radius, and that inbound and outbound intent are stated separately rather than inherited from one route.

## Three switches, and only one of them was set Whether the outside world can use a workload depends on three separate things, and this scenario has two of them right: 1. **The address** — a public address is attached, so the workload is addressable in principle. 2. **The filter** — the flow is permitted, so nothing is being denied by rule. 3. **The route** — and this is the one nobody checked. A route table is a list of destination prefixes with a target for each. Every packet **leaving** a subnet is matched against the table associated with that subnet; the most specific matching prefix wins; anything that matches nothing is dropped inside your own network. A newly cut subnet typically starts with one entry: the network's own range, targeted at local delivery. That is enough for workloads to talk to each other and to nothing else. ## Why the packet gets in and the reply does not This asymmetry surprises people, and it is worth being precise about it. - **Inbound.** The platform's internet-facing attachment owns the mapping between the public address and the workload holding it. A packet arriving for that address is delivered inward without consulting your subnet's outbound routing at all. - **Outbound.** The reply is not special. It is an ordinary packet from the workload toward an address on the public internet, and it is matched against the subnet's route table exactly like any other. No entry covers the caller's address, so it is discarded. The result is a **half-open path**: the request lands, the workload may even process it and log it, and the response evaporates. From outside, the connection attempt simply hangs until the client gives up. ## Reading the symptom | what the caller sees | what it usually means | |---|---| | hangs with no response at all | nothing carried the reply, or something dropped it silently | | immediate refusal | the packet arrived and nothing was listening on that port | | works from inside the network, hangs from outside | an inside-only path exists; the outward route or the outward filter is missing | | works for a while then stops | not this failure — look at state, not at the table | A hang narrows the field to two candidates: a missing path or a silent drop. The route table is the cheaper of the two to inspect, and in a subnet that was cut for private workloads it is the usual answer. If the workload's own logs show the request arriving, the path inward is proven and the missing piece is unambiguously on the way back. ## The fix, and what it does not do Add an entry to the table associated with that subnet whose destination covers everything not matched more specifically, targeted at the network's internet-facing attachment. Three consequences follow immediately, and all three belong in your answer: - **The subnet is now routed outward for every workload in it**, not just this one. Routing is a property of the subnet, not of the machine, so this is a blast-radius decision — which is why estates usually keep separate subnets for workloads that should be reachable and workloads that should not. - **Nothing about permission changed.** A route carries packets. Who may call the workload is still decided by filtering and by whatever the application authenticates; do not let a working path be read as an authorized one. - **Outbound reach came along with it.** The workload can now start its own flows to the internet directly, because that same default route serves both directions of initiation. If the intent was inbound only, that is a new surface to think about. ## Related failures with the same shape - A workload **moved** to another subnet stops being reachable, because routing travelled with the subnet's table, not with the workload. - An extra, **more specific** route added for a partner's range quietly diverts traffic to a different door, so only that partner's calls break while everything else is fine. - A public address is attached but the workload was given a **second interface** in an unrouted subnet and replies leave by that one; the table being consulted is not the table being edited. The habit worth demonstrating: when reachability is broken, check address, route and filter as three separate questions, in that order, and say which one you proved rather than which one you suspect.

  • The default route is added and the workload is reachable. Has anything changed about who may call it?
    No. The route made a path exist; permission is still decided by the filtering on that flow and by whatever the application itself authenticates. A reachable workload and an authorized caller are two separate facts, and conflating them is how an internal service ends up serving the internet.
  • Would moving the workload into a different subnet fix this?
    Only if that subnet's associated route table already carries the outward route. Routing is a property of the subnet, so the workload inherits whatever that subnet's table says — which is also why moving a workload for an unrelated reason can silently change its reachability.
  • How would you tell this apart from a silent drop by a filter?
    Prove each leg separately. If the workload's own logs show the request arriving, the inward path and the inbound permit both worked, so the fault is on the way back: either the outward route or a rule applied to the reply. Fix the route first, because it is the cheaper fact to establish.

saying these in an interview costs you the question

  • Thinks attaching a public address is enough to be reachable
  • Says the packet cannot have arrived if the reply failed
  • Assumes a hang always means a filter denied something
  • Treats routing as a property of the machine, not the subnet
  • Reads a working path as a granted permission