A freight API is reachable from inside its subnet and times out from the office across a VPN. The instance security group allows the API port from the office CIDR. The subnet NACL has no inbound allow for that port from the office CIDR, and a later rule denies the rest. What should change?
Select an answer to reveal the explanation.
Short Explanation
You’ve found the gap: the security group allows the office CIDR, but the subnet NACL denies traffic that has no matching allow. Add an inbound allow for the API port from the office CIDR before the deny; opening the security group to the internet won’t override the NACL.
Full Explanation
Both the security group and the subnet NACL must allow the packet. The security group already allows the office CIDR, but the NACL has no matching inbound allow and reaches a later deny, so the packet is dropped at the subnet. Add an inbound NACL allow for the API port from the office CIDR before the deny; NACL rules are evaluated in number order, and the first match wins. Opening the security group to 0.0.0.0/0 does not override the NACL deny and unnecessarily expands exposure. Replacing the customer gateway does not fix the issue: security groups can evaluate traffic arriving over a VPN, and the missing rule is in the NACL. Deleting the subnet to remove its NACL destroys the workload rather than correcting access. Exam caveat: NACLs are stateless, so return traffic also needs an outbound allow for the ephemeral ports; otherwise, the inbound request may arrive while the response is dropped. As a practical check, test the API port from the office and inspect a subnet flow log for ACCEPT rather than REJECT for that CIDR. Put the office-CIDR allow ahead of the deny, and verify the outbound ephemeral-port rule if the timeout persists.