Ephemeral Ports

Ephemeral ports let applications communicate without requiring a permanently assigned local port for every outgoing connection. When an application opens a TCP connection without explicitly selecting a local port, the operating system chooses an available port from its configured ephemeral range. UDP applications can receive a similar automatic assignment when binding or sending through a socket. The assignment belongs to the socket rather than to an individual packet, and a long-lived connection can retain an ephemeral port for hours.

Consider a virtual machine at 10.0.1.10 connecting to an HTTPS server at 203.0.113.20. The initial TCP packet might use source port 53024 and destination port 443. The reply uses source port 443 and destination port 53024. Allowing destination port 443 in both directions therefore does not, by itself, permit the reply. The return packet is addressed to the client's temporary port, not to another HTTPS listener.

The required firewall configuration depends on whether the control tracks connection state. AWS security groups are stateful: response traffic for an allowed flow is automatically permitted, regardless of rules in the opposite direction. An instance allowed to initiate HTTPS connections does not need an additional inbound security group rule opening its ephemeral range solely for those responses. Likewise, a server security group that allows inbound HTTPS does not need a separate outbound rule solely for replies to those accepted connections.

Network access control lists in Amazon VPC are stateless, so both directions require appropriate rules. For an HTTPS client subnet, a restrictive network ACL generally needs outbound TCP destination port 443 and inbound TCP destination ports covering the client's ephemeral range. For an HTTPS server subnet, it generally needs inbound destination port 443 and outbound destination ports covering the clients' ephemeral ranges. Scope the applicable source or destination address ranges as tightly as the architecture allows, and account for ordered ACL rules and explicit denies.

There is no universal operating-system ephemeral range. IANA designates 49152–65535 as dynamic or private ports, but operating systems and managed network components can use different ranges. Linux commonly uses 32768–60999, although configuration varies. AWS network ACL guidance often uses 1024–65535 to accommodate diverse clients or components. Treat that broader interval as a compatibility allowance, not as the definition of ephemeral ports. Inspect host configuration and relevant service requirements before narrowing rules.

Load balancers, proxies, and network address translation devices add another consideration: they may create separate connections or translate source ports. A backend can therefore see the load balancer's connection rather than the original client's transport connection. Apply rules to each actual network leg instead of assuming that one source port remains unchanged throughout the path.

Broader stateless port allowances improve compatibility but permit more traffic at that network layer, so combine them with tightly scoped addresses, stateful controls, and application authentication. Ephemeral ports are not inherently trusted, and a high-numbered port is not necessarily ephemeral. Port capacity is also finite: heavy connection churn, TCP TIME_WAIT, and shared NAT translation limits can cause allocation failures. Connection pooling, connection reuse, and additional source-address capacity can help, depending on the bottleneck. During troubleshooting, inspect source and destination ports in flow logs or packet captures and check both directions of every stateless boundary.