Inbound allowed, replies not
Establishes and then hangs, with a security group that is plainly correct
100 inbound allow tcp 443 0.0.0.0/0 100 outbound allow tcp 443 0.0.0.0/0
If a security group is open and the connection still hangs, this is almost always why. A network ACL is stateless, so the reply needs a rule of its own.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Check. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Establishes and then hangs, with a security group that is plainly correct
100 inbound allow tcp 443 0.0.0.0/0 100 outbound allow tcp 443 0.0.0.0/0
Evaluation stops at the first match, so the allow never runs
100 inbound deny tcp 443 0.0.0.0/0 200 inbound allow tcp 443 0.0.0.0/0 100 outbound allow tcp 1024-65535 0.0.0.0/0
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
The reply goes to the client's ephemeral port, not back out through 443, so the rule covers nothing and the connection still hangs.
Instead:Add an outbound allow for 1024-65535.
Network ACL rules stop at the first match in number order, so a deny only wins if it is reached first.
Instead:Renumber so the specific rules come first, and leave gaps of a hundred.
A custom ACL starts with nothing but the implicit deny, so every connection stops the moment it is attached.
Instead:Add the rules first, then associate the subnet.
It goes to the client's ephemeral source port. So an outbound rule for 443 does nothing for a connection that arrived on 443, and the connection establishes and then stalls.
Linux uses 32768-60999, Windows Server uses 49152-65535, and load balancers and NAT gateways use the whole of 1024-65535. Since you do not control the client, allowing 1024-65535 is the practical answer and narrower rarely pays.
An instance calling an external API on 443 receives the response on its own ephemeral port, so an inbound allow for 443 does not cover it. This is the one that breaks package installs and API calls from a private subnet.
Rules are evaluated in ascending number order and stop at the first match, so a lower-numbered deny shadows a higher-numbered allow and a later deny after an allow is dead. That is the opposite of an IAM policy, where an explicit deny always wins.
The convention is to number in hundreds so a rule can be inserted between two without renumbering everything. Renumbering an ACL in place is exactly the sort of change that takes a subnet offline for a moment.
A VPC's default network ACL is invisible until somebody edits it. One created by hand starts with only the implicit final deny, so attaching it to a subnet blocks all traffic until rules are added.
Stateful, allow-only, and attached to interfaces rather than subnets. If both are in play, the ACL is the one that needs rules in both directions.