Why a VPN Gives You Two IP Addresses

When a VPN connects, your device does not simply swap one address for another. It gains a new virtual network adapter with its own address, assigned by the VPN server from the provider’s internal network. Your original adapter and its address stay exactly where they were, still carrying the encrypted tunnel itself.

So a connected device holds at least two addresses at once, and the difference between them explains most of what looks strange about VPN routing.

The tunnel is an ordinary-looking adapter

Operating systems handle VPNs by pretending they are network cards. The VPN client creates a virtual adapter — you may see it named as a TUN or TAP device, or with the protocol’s name — and the operating system treats it like any other interface: it has an address, a subnet mask, a set of DNS servers, and a place in the routing table.

That is a deliberate piece of design. It means every application on the machine can use the tunnel without knowing anything about VPNs. A browser asks the operating system to reach an address; the routing table says the virtual adapter is the way there; the client encrypts the packet and hands it to the real adapter to send. No application-level cooperation is required.

It also means the tunnel is subject to the same rules as any other interface, which is where the interesting behaviour comes from.

Which address is which

Three addresses are typically in play, with three different scopes.

Your LAN address, on the physical adapter — something like 192.168.1.x. This is your device’s identity on your own network, handed out by your router, and it is unchanged by the VPN. The tunnel’s encrypted packets leave the machine from here.

Your tunnel address, on the virtual adapter. Also private, but from the VPN provider’s internal range, not yours. This is your identity inside the provider’s network. It is what the VPN server uses to route replies back to you specifically, distinguishing you from the other users connected to the same server.

The exit address, which is not on your device at all. It belongs to the VPN server, and it is what websites see. Your traffic is translated onto it at the server — the same kind of translation your home router performs, one hop further out.

The scope distinction is exactly the one in public vs private IP addresses, applied twice.

Why the tunnel address is worth knowing

It clears up several questions that otherwise have no good answer.

Why does a leak test never show the tunnel address? Because it is private and only meaningful inside the provider’s network. A site can no more see it than it can see your 192.168. address. What a leak test shows is the exit address — or, if something is wrong, your provider’s public one, which is the distinction to keep in mind when reading whether your VPN is leaking.

Why do many users appear to share one address? Because the server translates all their tunnel addresses onto the same exit address. Internally they are distinct; externally they are one. This is the mechanism behind shared addressing described in shared vs dedicated VPN IP addresses.

Why does the client know when the tunnel is up? Because it can watch the virtual adapter’s state directly, independently of whether any traffic is flowing.

The routing table decides everything

With two adapters available, something has to choose which one to use, and that something is the routing table.

A VPN client typically installs a route saying “send everything through the virtual adapter”, plus a narrow exception for the VPN server’s own address so the tunnel’s encrypted packets can still reach it over the physical adapter. Without that exception you would have a loop.

Most VPN oddities trace back to entries in this table:

• Local devices become unreachable. If the client routes even local-network destinations into the tunnel, casting and printing break. Clients usually expose this as a “local network access” toggle.
• Only some apps use the tunnel. That is split tunnelling, implemented by applying different routing or policy rules per application.
• Traffic reverts to the open connection on drop. If the virtual adapter goes away, the original route becomes the best available one and traffic flows normally — unencrypted. Preventing that is precisely what a kill switch does, usually by installing firewall rules rather than by watching for the drop.
• Two VPNs conflict. Two clients both claiming the default route produce unpredictable results, which is why chaining tunnels is normally done at the provider’s end rather than on the device.

DNS gets its own set of two

The virtual adapter carries DNS server settings as well as an address, and this is a frequent source of leaks.

Ideally the client replaces your system resolver with one reachable through the tunnel, so name lookups go where your traffic goes. But an operating system can hold resolver settings per interface and may query several at once, or fall back to the physical adapter’s resolver when the tunnel’s is slow. The result is queries escaping to your provider’s resolver while everything else is tunnelled — the mechanism behind a DNS leak.

Checking that name resolution uses the tunnel is a separate test from checking the exit address, and passing one says nothing about the other.

What to look at when something is wrong

Enumerate your interfaces before theorising. Listing the adapters and their addresses tells you immediately whether the tunnel exists at all, whether it has a sensible address, and whether it holds the DNS servers you expect.

From there the questions are ordered:

1. Does the virtual adapter exist and have an address? If not, the tunnel never came up and this is a connection problem.
2. Does the routing table send default traffic through it? If not, the tunnel is up but unused — which looks exactly like the VPN doing nothing.
3. Is the exit address the provider’s? If not, traffic is escaping despite a healthy tunnel.
4. Do lookups use the tunnel’s resolver? If not, you have a DNS leak with an otherwise correct tunnel.

That sequence separates four failures that all present identically in the app’s status display, and it works because each step tests one of the two addresses rather than the connection as a whole.