Cloud Security Group for a VPN: Open the Listener, Not All

The VPN server is running, the client times out, and the first instinct is to add an allow-all rule to the security group. That sometimes makes it work, which is the worst outcome, because now nobody knows which boundary was actually closed. Four separate filters sit between the client and the daemon, and only one of them is the security group.

Name the protocol before the rule

A rule is a protocol, a port range and a source. WireGuard listens on UDP, commonly 51820. OpenVPN is usually UDP or TCP 1194 depending on how it was configured. IPsec needs its IKE exchange on UDP 500 and 4500 plus the ESP protocol itself, which is a protocol number rather than a port. Guessing TCP because the other rules are TCP is how people end up with a rule that looks right and matches nothing.

Read the listener from the running service, not from a tutorial. A daemon bound to one address will not accept traffic arriving on another.

Restrict the source to the client range the design allows, rather than the whole internet.

Security groups are stateful; subnet ACLs are not

Security groups are stateful and allow-only: a permitted inbound flow gets its replies automatically, and there is no deny rule to reason about. Subnet ACLs are stateless and evaluated in both directions, so an inbound allow without the matching outbound ephemeral range still fails. That difference explains a lot of rules that look correct in the console.

Confirm which policy is attached to the running endpoint as well, since an instance can have more than one group and a rule in an unattached group changes nothing.

The effective policy is the union of what is attached, not the file you edited.

The host firewall is a separate boundary

The cloud policy admits traffic to the network interface, and then the operating system decides whether the daemon sees it. A host firewall with a default deny policy will drop a packet the security group allowed, and the cloud console will show no denial because it never had an opinion. Check both, in the order the packet meets them.

If the host uses a distribution firewall front end, confirm the underlying rules rather than the profile name, because a profile can be active while the port is closed.

A capture on the interface tells you which boundary dropped the packet.

Admitting the listener is not routing the clients

A VPN gateway that forwards client traffic needs more than an open port. It needs IP forwarding, a policy permitting the flow from the tunnel interface to the destination network, and often a source-destination check disabled on the interface so the platform does not discard traffic not addressed to it. None of that is created by the listener rule.

This is where a working handshake and a broken data path diverge, and why a tunnel status can look healthy while nothing loads.

Fix routing as a separate change with its own verification, and note that a forwarding gateway also needs an egress policy that allows the destination.

Keep a way back in, then narrow the rule

Before changing remote firewall policy, confirm an independent management path exists, such as a session manager, a serial console or an out-of-band network. If the only management path runs through the rule you are editing, you have no recovery. Then apply the narrow rule, test from a real client, and correlate the attempt with server-side evidence. A response from another service on the same machine is not proof that the listener was reached.

Remove any experimental broad allowance as soon as the narrow one works, and note why the rule exists. AWS documents the stateful behaviour of security groups, and that document is the one to cite when someone proposes a wide range as a shortcut.

Document the attachment too, or a replacement interface will silently lose the policy.