A subnet's custom network ACL in AWS has an inbound rule allowing TCP 443 and an outbound rule allowing TCP 443, and the instances' security groups allow 443 inbound. Clients still time out. What is wrong?

## What actually goes over the wire A TCP connection has two endpoints with two ports. The client picks a local port from its operating system's *ephemeral* range — a high-numbered, essentially arbitrary port used for the lifetime of that one connection — and connects to the server's well-known port, 443. So the flow looks like this: ``` request: client:51314 -> server:443 reply: server:443 -> client:51314 ``` Only the request carries 443 as a *destination*. In the reply, 443 is the **source** port and the destination is the client's ephemeral port. ## Why the network ACL drops the reply A network ACL is attached to a subnet and is **stateless**: it keeps no record that it just admitted a request, so the reply is evaluated from scratch against the rules for the direction it is travelling. The outbound rule in the question permits TCP with destination port 443. The reply's destination port is 51314. No rule matches, so it falls through to the implicit final rule, which denies. The server sends its SYN-ACK, the subnet swallows it, and the client sits in `SYN_SENT` until it times out — which is exactly the symptom described: a hang, not a refusal. This is the single most common way a hand-written NACL breaks a working system, and it is why interviewers reach for it: it can only be diagnosed by someone who has internalised what "stateless" means, rather than memorised the word. ## The correct rule set For a subnet hosting HTTPS servers: ``` inbound 100 allow tcp 443 0.0.0.0/0 outbound 100 allow tcp 1024-65535 0.0.0.0/0 ``` The outbound rule is deliberately wide because you cannot know which ephemeral port any given client picked. AWS's documented recommendation is `1024-65535`, chosen to cover every client you might see. The underlying ranges differ by stack: Linux kernels default to `32768-60999` (exposed as `net.ipv4.ip_local_port_range`), Windows Server 2008 and later use `49152-65535`, and AWS's own NAT gateways and Elastic Load Balancing nodes use `1024-65535`. If your traffic arrives via a NAT gateway or a load balancer, that last range is the one that matters, so narrowing the rule to the Linux range would break it. ## The mirror case The same trap exists in the other direction and catches people just as often. If instances in the subnet *call out* — to an API, to a package repository, to an RDS endpoint — you need: ``` outbound 100 allow tcp 443 0.0.0.0/0 inbound 100 allow tcp 1024-65535 0.0.0.0/0 ``` That inbound ephemeral rule is uncomfortable to write, because it looks like you are opening the subnet to the world on 65,000 ports. In practice you constrain it by CIDR where you can, and you rely on the *security group* to do the real filtering — the packet still has to get past an instance-level allow rule, and a stray packet to a high port with no listening socket goes nowhere. ## Why the security groups are not the problem Security groups attach to elastic network interfaces and are **stateful**: they track the connection, so a reply to an admitted request is permitted outbound regardless of the outbound rules, and the reply to a connection the instance originated is permitted inbound. You never write ephemeral-port rules in a security group. If a candidate proposes adding an ephemeral outbound rule to the security group as the fix, they have not understood which of the two filters is stateless. ## How to confirm it quickly VPC Flow Logs on the instance's ENI settle the argument. You will see an `ACCEPT` record for the inbound request and a `REJECT` record for the outbound reply carrying the same addresses with the ports reversed. Since a stateful security group never rejects the reply to a flow it admitted, an outbound `REJECT` on an accepted flow points at the subnet's network ACL. ## The lesson beyond the puzzle This is the strongest practical argument for leaving network ACLs at their permissive default and doing segmentation in security groups. Every stateless rule you write is a rule you have to write twice, in a direction that is not intuitive, over a port range you have to guess correctly for every client stack that will ever talk to the subnet.