An EC2 Elastic IP is not the instance's private VPN address

The instance has a private address, the Elastic IP is associated with it, and a route for that public /32 gets added to the VPN in the hope that the two become the same thing. They do not. An Elastic IP is a translation performed outside the guest, by the internet gateway, on traffic that takes the internet path. The guest's operating system never sees that address configured on an interface. Adding it to a tunnel interface does not reproduce the upstream translation, and it creates a second, conflicting identity for the same machine.

Two addresses, one instance

The instance's network interface holds a private address inside the VPC, and that is the address the guest knows about. The Elastic IP is associated with the same interface but lives on the public side of the mapping.

Anything that reaches the instance through the internet arrives translated to the private address. Anything the instance sends to the internet leaves with the Elastic IP as its source, again because of that translation.

Inside the guest, one address exists. Outside, two do. That asymmetry explains most of the confusion in this area. The guest cannot configure what the gateway translates. It can only answer on the address it actually holds.

What the internet gateway actually does

AWS's internet-gateway documentation describes the arrangement: the instance is aware of its private IPv4 address, and the gateway provides the corresponding public IPv4 or Elastic IP translation for traffic on the internet path.

That is network address translation, not an alias. The mapping is maintained by the gateway, tied to the association, and only applies to packets that traverse it. Remove the association and the public identity disappears without the guest noticing anything.

This is why a private VPN packet addressed to the public /32 is not reinterpreted as a private packet to the guest's local address. The packet follows the route it matches, which sends it to the internet gateway, and the gateway's behaviour depends on the path being permitted in both directions.

Why the tunnel-interface trick fails

Assigning the Elastic IP to a tunnel interface asks the guest to treat a public address as local. Now two things claim the same address: the gateway's translation on the internet path and the local interface inside the tunnel. Return traffic has no consistent answer about which one applies.

Even when it appears to work, the design has hidden the real question. Clients either reach the private address through the tunnel or they reach the public endpoint through the internet, and the two paths have different security groups, different logging and different failure modes.

The address was never the problem. The path selection was.

Three goals, three designs

If the goal is a public VPN endpoint, the Elastic IP is the right tool: remote peers connect to it over the internet and the encrypted transport terminates on the instance. The inner application traffic then uses the private address.

If the goal is private access to the application, the destination is the private address or a private DNS name that resolves to it, and the VPN route, security group and return path all have to agree. The Elastic IP does not appear in that design at all.

If the goal is a stable public egress identity for VPN users, that is a NAT design on the egress side, not an address on the client's tunnel. Three goals that sound similar produce three different diagrams, and only one of them involves putting an Elastic IP somewhere new.

Verify the path you chose

For private access, confirm the VPN route covers the private prefix, the VPC route table returns traffic to the tunnel, the security group permits the client source and the client's own firewall allows the reply. Then test one real request rather than a ping.

For public access, confirm the client's internet egress, the public entry's routing and its security policy. Whether a VPN client can reach a public endpoint through the tunnel depends on the tunnel's egress and firewall rules, not on the Elastic IP association.

If a public hostname has to work from both sides, use a DNS design that answers with the private address for VPN clients and the public address for everyone else, and keep the certificate valid for the name rather than the address. Order of work: name the goal, pick the address that belongs to it, then verify routes, policy and one request.