VPN: How a Tunnel Changes the Address Websites See

You turn on a VPN, and a website suddenly thinks you are in Frankfurt. Your laptop has not moved. The place where your internet traffic emerges has changed: it now leaves through a VPN server, and the website sees that server's public address. IP-based location is approximate, but it follows this exit address rather than your café's address.

Two mechanisms produce that result. The tunnel carries your original packet to the VPN server. NAT at the server gives it a public source address for the next part of the trip. Keeping those operations separate makes the whole story easier to follow. If address rewriting is unfamiliar, start with how NAT works.

A tunnel is a packet inside a packet

Your browser wants to reach a website at 198.51.100.20:443. In this example, routing sends that connection through a VPN interface whose address is 10.8.0.2.

The original IP packet is the inner packet: source 10.8.0.2, destination 198.51.100.20. The VPN encrypts that packet and puts it inside a new outer packet addressed to the VPN server at 198.51.100.80. The public internet routes the outer packet using that visible destination. It does not need to understand the encrypted material inside.

There are two destinations because the packets have two jobs:

• Outer destination: VPN server. This gets the encrypted package to the tunnel's other end.
• Inner destination: website. After removing the wrapper, the VPN server uses this to forward the original traffic.

The laptop and VPN server authenticate their tunnel traffic and establish encryption keys as part of the VPN protocol. The figure uses WireGuard as the example: its encrypted data packets are carried over UDP. Port 51820 is a common example configuration, not a universal requirement. WireGuard protocol description.

Follow the full tunnel

Step through the journey below. The locked inner panel means its IP header is hidden from observers along that part of the route. Switch to No VPN to compare the direct path.

The café router still applies NAT. It changes the outer source from the laptop's Wi-Fi address to the café's public address, 203.0.113.7. It cannot rewrite the encrypted inner header. On the return trip, the café reverses that outer mapping and sends the encrypted package back to the laptop.

Notice the difference between the café Wi-Fi and the ISP. On the local wireless link, the packet comes from the laptop's private address, 192.168.1.10. After the router's NAT, the ISP sees a packet from the café's shared public address. Both can see that the tunnel goes to the VPN server, along with packet lengths and timing. Neither gets the inner website address from these encrypted packets.

This is an authored IPv4 illustration, not a capture of a real VPN. Public addresses use documentation ranges; source ports and timing are illustrative. It shows the data path after tunnel setup, leaving out handshakes, DNS requests, retransmissions and packet fragmentation.

Why the website sees the VPN's IP

Removing the wrapper only exposes the inner packet. Its source is still the private tunnel address 10.8.0.2, which cannot be used as a public internet return address.

For this consumer internet-exit example, the VPN server applies source NAT: it replaces 10.8.0.2:51000 with its public exit address and a mapped port, 198.51.100.80:45001. The website receives that translated packet, so the source of its connection is the VPN exit address. When the website replies, the server reverses this mapping, encrypts the reply for the tunnel and sends it back.

Encryption explains how the traffic crosses to the VPN server privately. NAT explains the public source address the website sees in this example. The figure uses one public address for VPN entry and internet exit; providers can use different addresses for those roles. NAT is also not a requirement for every VPN: a company VPN may route packets to internal addresses without translating them.

Full tunnel versus split tunnel

This is a routing choice on your device.

With a full tunnel, ordinary internet destinations use the VPN as their default route. The outer packets that reach the VPN server itself still need a path through the physical network; otherwise the tunnel would try to carry itself. Local-network routes and other exceptions depend on the client configuration. WireGuard's routing documentation shows both endpoint exceptions and policy-routing approaches. WireGuard routing and network namespaces.

With a split tunnel, selected traffic uses the VPN and the rest takes the direct route. In the next figure, both connections come from the same laptop using the same consumer VPN:

• The website goes through the VPN and sees the VPN exit address.
• The bank goes directly through the café and sees the café's public address. This is an example routing policy, not a recommendation to bypass a VPN for banking.

The bank connection still uses HTTPS. Bypassing the VPN removes the extra tunnel layer; it does not remove the browser's HTTPS encryption. Company VPNs often use split routing for a different purpose: only traffic for the company's internal network enters the tunnel.

What a VPN hides, and who you trust

HTTPS and a VPN protect different parts of the path. HTTPS encrypts application data between the browser and the website. A VPN adds encryption between the device and the VPN server, including the original IP header. Removing the VPN layer does not decrypt the HTTPS layer. TLS 1.3, introduction.

This table describes the website connection in the full-tunnel example, assuming DNS and other relevant traffic also use the tunnel:

Without the tunnel, hostnames may also be visible through unencrypted DNS or the TLS ClientHello. Encrypted DNS and Encrypted ClientHello can reduce that exposure; they do not hide the destination IP itself. With the tunnel, DNS queries sent to a café or ISP resolver outside it can still expose the names you look up. The route and DNS configuration matter as much as the VPN toggle. DNS over HTTPS, Encrypted ClientHello.

The VPN server becomes a party you must trust with the metadata it can observe. It can read unencrypted application traffic leaving the tunnel, but it does not automatically gain the keys for HTTPS traffic. A website can still recognize a login or a cookie even when your source IP changes. A VPN changes the network path and the visible source address; it does not make every part of your identity disappear.

The protocols, briefly

WireGuard, IPsec and OpenVPN can all provide encrypted tunnels, but their packet formats and setup differ. WireGuard carries encrypted data over UDP. OpenVPN can use UDP or TCP. IPsec commonly carries protected data in ESP, which runs directly over IP and has no ports; when NAT traversal is negotiated, ESP is wrapped in UDP, commonly on port 4500. That wrapper lets a NAT track the flow using ports. The NAT page's IPsec example shows why it helps. WireGuard protocol, OpenVPN transport documentation, RFC 3948: UDP encapsulation of ESP.

Related concepts