Why GRE and ESP fail through an AWS NAT gateway

The tunnel fails, the security group already allows all traffic, and the conclusion is that AWS is blocking the VPN. It is not blocking anything. A managed NAT gateway forwards a documented set of outer protocols, and native GRE or native ESP are not in it, so no rule you add will make the gateway carry them. The allow rule and the transport capability are two different things, and only one of them is yours to change.

The rule set is not the protocol set

A security group decides which traffic is permitted to leave the instance. The NAT gateway decides what it is able to translate and forward. When the second limit applies, a permissive rule produces exactly the symptom people misread as a firewall problem: packets leave the instance, the control exchange may even complete, and nothing arrives at the peer.

AWS's NAT gateway protocol specification lists TCP, UDP and ICMP for the managed service. That is the whole supported set. An allow rule for another IP protocol cannot extend it, because the rule is evaluated long before the gateway's forwarding path is reached.

The distinction matters because the two failures look identical from the client and have completely different fixes.

PPTP shows why a port test lies

PPTP is the clearest legacy example of a port check that proves nothing. It opens a TCP control connection on port 1723 and then carries the tunnel data over GRE, which is IP protocol 47. Protocol 47 is not TCP port 47, and the two numbers have nothing to do with each other beyond sharing digits.

An operator who tests connectivity to 1723 and sees a completed handshake concludes the path works. The data channel then never passes a single packet, because the gateway has no GRE support to offer. That is an interpretation of a legacy protocol's requirements, not advice to deploy PPTP, which has been obsolete for years.

The same reasoning applies to any protocol whose control channel is TCP or UDP while its data path is not.

IPsec survives only as UDP

IPsec is the case where the answer is conditional rather than a flat no. AWS documents NAT traversal as the supported arrangement for IPsec through a NAT gateway. With NAT-T negotiated, ESP is encapsulated inside UDP and the gateway sees ordinary UDP rather than protocol 50.

Allowing UDP 4500 does not make endpoints use NAT traversal. It only permits the packets if they are already shaped that way. Confirm from the client's own negotiation output which encapsulation was chosen, and confirm on the receiving side that the peer accepted it. Two endpoints configured for native ESP will keep sending native ESP no matter what the rule set says.

A TCP- or UDP-based VPN fits the documented transport set and can still fail for routing, filtering or authentication reasons. Fitting the set is necessary, not sufficient.

Check the path before widening policy

Verify the workload subnet's actual route and the identity of its next hop first. A direct public path, a NAT instance, a managed NAT gateway and a private path through a transit gateway are four different designs, and only one of them is the managed service described here.

Then record the attempted endpoint, the address family, the outer protocol and the port where the protocol has one. Use the client's diagnostics and the network owner's flow observations rather than a successful browser request, which proves only that TCP and UDP work. After that, review the security group, the subnet ACL, the guest firewall and the service policy for both directions of the flow.

Do not open all traffic to compensate for a transport the service cannot carry. The rule change will not fix it, and it will outlive the incident.

When the transport does not fit

If the outer protocol is outside the supported set, the fix is architectural: choose a transport the path can carry, or move the egress to something that carries the one you need. OpenVPN over UDP, WireGuard over UDP and TLS-based tunnels all fit the documented set. A customer-managed NAT instance is the option when a specific protocol must pass and the operational cost of running it is acceptable.

Hosting an inbound VPN server is a separate problem with a separate answer. A NAT gateway provides outbound translation and no general inbound port forwarding, so a server behind it needs its approved public entry designed on its own terms.

Order of work: name the outer protocol, confirm the next hop, compare it with the documented set, then change architecture or transport. A different port number cannot turn GRE into TCP, and one more permissive rule cannot turn a completed control exchange into a working data channel.