Exercise 2: The Missing Ephemeral Outbound Port NACL Gotcha — Possible Solution ==================================================================== The setup: an inbound NACL rule allows port 443, but the outbound NACL rule for the ephemeral port range (roughly 1024-65535) needed for the RESPONSE was never added. Walking through what happens: 1. A client sends a request to the server on port 443. The inbound NACL rule explicitly allows this -- the request reaches the server successfully. 2. The server processes the request and attempts to send its RESPONSE back to the client. Per how TCP/IP connections work, this response travels from the server's port 443 back to whatever EPHEMERAL port the client's operating system originally opened for this connection (a random high port number, not 443 itself). 3. Because NACLs are STATELESS (per this chapter and `cloud1-5`'s own explanation), the NACL doesn't automatically recognize this outbound response as "part of an already-permitted inbound connection" -- it evaluates it as its own, completely separate packet, against the OUTBOUND rules specifically. 4. Since no outbound rule permits traffic on the ephemeral port range, the response packet is BLOCKED on its way out, even though the original inbound request was allowed through without any problem. What a user would actually observe: The connection attempt appears to "hang" or eventually TIME OUT -- per this chapter's own failure-type table, a timeout specifically indicates a silent drop somewhere, which is exactly what's happening here. Critically, this would NOT look like a "connection refused" error, because the server DID receive the request and DID respond -- the response was simply never allowed to complete its journey back. From the client's perspective, it looks exactly like nothing is listening at all, even though the server processed the request correctly the entire time. WHY THIS WORKS AS AN ANSWER ------------------------------ This traces the exact mechanism the chapter names -- NACLs being stateless and requiring a separate outbound rule for return traffic -- through a concrete request/response sequence, and specifically connects the observed symptom (a timeout, not a refusal) back to the chapter's own failure-type table, showing why this particular misconfiguration produces that specific, and specifically confusing, symptom.