Two Devices, One Wi-Fi, Different VPN Exits: What Decides

Two laptops on the same home router can reach the internet through different VPN exits, and the shared Wi-Fi has nothing to say about it. What decides the outcome is where the tunnel runs and which policy chooses the path for each request. The opposite belief is just as common and just as wrong: two devices with separate profiles do not automatically produce two public addresses. Both mistakes come from treating one address as if it were three.

Three addresses, and only one of them leaves

A laptop has a home-LAN address that identifies it on the local segment, and it may also have a tunnel address assigned inside the VPN. Neither of those is visible to a remote service. What that service records is the public egress address of whatever device finally sends the packet, after any translation along the way.

RFC 3022 draws the distinction that explains most confusion here. Traditional NAT maps internal addresses to public ones, while port translation lets many internal addresses share a single public address at the same time. A household with one public address and several devices is the second case, and it is the default almost everywhere.

Count the public addresses, not the profiles. Two clients with different tunnel addresses and the same exit policy produce one observed address, and a single client with a differently routed exit can produce another. That single comparison is the whole test. Everything else is an assumption about the far end.

What makes two exits actually different

An exit is different when the last device before the internet uses a different public address for that traffic. That can happen because the VPN terminates in a different location, because the exit pool assigns a different address, or because the provider routes the request through a different egress. All three are policy decisions made at the far end, and none of them are visible from the home router.

Two devices that each run their own client with the same profile usually land in the same pool and often receive the same exit for a given session. That is not a bug, it is the normal behaviour of a shared pool. Getting distinct exits usually means asking the service for distinct assignments rather than configuring the client twice.

Read the service terms about simultaneous connections before designing around a guarantee. A second login is permission to connect, not a promise of an exclusive address. If the terms are silent, ask the provider instead of assuming. The answer changes the design more than any client setting does.

Why separate profiles are not separate egress

A profile describes how to reach the VPN and how to authenticate, and it says almost nothing about what happens afterwards. The exit is chosen by the far end, where routing, address pools and translation policy live. Duplicating a profile on a second machine duplicates the client configuration, not the server's decision.

The reverse also holds. One VPN server can present more than one public egress when its routing and translation policy are built that way, while separate servers may feed a single downstream exit. So the number of server names in your configuration says nothing about the number of addresses. That is why the configuration is the wrong place to look for this answer.

The only reliable answer comes from a request made through the arrangement you intend to use. Everything else is inference.

Where to put the separation

A router tunnel covers the whole household, which is convenient and produces exactly one shared exit for every device behind it. A client on each device gives you per-device control but requires each device to be provisioned and to stay provisioned. A policy-capable router sits in between, choosing a path per device, and it only works if it can identify devices reliably across reconnects and DHCP changes.

Creating another private DHCP lease on the router is not the same as creating another public address. It changes the local view and leaves the exit untouched. The separation lives in the exit policy, whether that policy is on the router or at the VPN service.

Whichever shape you choose, write down the ownership: who provisions a device, who rotates its credential, and who notices when it stops using the intended path.

Check the exit you actually got

Make the check from the application that matters, and compare the same address family on both devices. An IPv4 result from one and an IPv6 result from the other proves nothing about either. Then repeat the check after a reconnect, because pool assignment can change between sessions.

Run it from a terminal inside the tunnel policy, not from a device that bypasses it. The wrong host produces a confident wrong answer.

curl -4 -sS https://api.ipify.org; echo
curl -6 -sS https://api64.ipify.org; echo
ip route get 1.1.1.1

If both devices print the same IPv4 address, they share an exit regardless of how many tunnels are up. Then decide what happens when the tunnel fails: a client that falls back to the direct path puts both devices back on the home address, and the separation disappears without an error. Confirm that fallback behaviour before you describe the arrangement as two exits, and remember that different addresses are a network result rather than two anonymous identities.