Does Your Phone's VPN Cover the Laptop on Its Hotspot?

The phone's browser reports an address in another country and the laptop on its hotspot still reports the mobile carrier. Neither observation is wrong, and the contradiction people see comes from assuming that sharing an internet connection also shares a tunnel. Three conditions decide whether tethered traffic enters the phone's VPN, and only one of them is about the phone's settings. Work through them before you look for a sharing feature that may not exist.

What the hotspot actually forwards

Tethering gives the laptop a path to the internet through the phone's mobile interface. The phone forwards those packets and, in the ordinary case, translates the laptop's addresses as they leave. That is a forwarding function, and forwarding is not the same as capturing traffic into a tunnel.

Whether the forwarded packets then enter the phone's VPN depends on how the VPN application installed its routes and rules. An application that captures only traffic originated on the phone will not see packets the kernel is forwarding on behalf of a tethered client.

That is why the two observations coexist so easily. The phone's own browser uses the tunnel, the laptop's packets take the forwarding path, and nothing in either display is lying to you. The two devices are simply not asking the same question of the same interface. Once you see the split, the "why is my laptop not protected" complaint becomes a design question rather than a bug.

Condition one: which tunnel the phone is running

Start by identifying the VPN's scope on the phone. A full-device tunnel, a per-application tunnel and a browser-only proxy are three different things, and only the first has any chance of covering forwarded traffic. Look at the provider's description of what the app captures rather than at the status bar icon.

Then check what the provider says about tethering. Some document explicitly that ordinary hotspot traffic is outside the tunnel, which is the honest answer for a consumer service that never promised to be a router. Proton VPN's Android hotspot guidance is one published example of that distinction; your provider's own documentation is the one that matters for your device.

A VPN icon in the status bar tells you the phone has a tunnel. It does not tell you which interfaces that tunnel covers, and that gap is where most of the confusion lives.

Condition two: whether tethering is included

Even a full-device tunnel may exclude forwarded traffic by design, because the application's routing rules were written for locally generated packets. Including tethered clients usually requires the provider to support it explicitly, or a rooted device with custom rules that most people should not attempt.

Switching from Wi-Fi to USB does not change this. The tethering subsystem supports several transports, but the transport is not the routing decision. A cable makes the link more stable and does nothing for tunnel coverage, which is why the advice to "just use USB" answers a different question than the one being asked.

Old recipes that flush firewall rules and assume particular interface names are not portable instructions. They were written for a specific device, a specific ROM and a specific year, and applying them to a current handset is more likely to break tethering than to extend a tunnel.

Condition three: whose identity the destination needs

This is the condition that usually settles the design, and it has nothing to do with hotspots. If the laptop needs to reach an employer's network, the identity that matters belongs to the laptop, and a consumer VPN on the phone cannot supply it.

ip -brief addr show
curl -sS https://ifconfig.me/ip
dig +short myip.opendns.com @resolver1.opendns.com

Run those on the laptop, not on the phone, because the question is what the destination sees from the device you care about. A public address reported by the phone answers a question about the phone.

Even a matching result from the laptop is limited evidence. Name resolution, other applications and behaviour when the tunnel fails all belong to the device whose coverage you are testing, and one HTTP request does not characterise any of them. Test the application you actually care about, then test it again with the tunnel deliberately disconnected.

What to do instead, in order of effort

The cheapest correct answer is to run the VPN on the laptop. Connect it to the hotspot, let the phone supply the underlying mobile connection, and establish the tunnel from the device that needs the identity. This works with employer VPNs, which is the case that matters most.

If the device cannot run a VPN client at all, look for an explicitly supported sharing gateway or a travel router that terminates the tunnel. Read its documentation for the actual platform rather than assuming a hotspot feature is that gateway.

If neither is possible, accept the limitation rather than working around it with a recipe you cannot maintain. The phone's VPN covers the phone; the laptop needs its own path, and knowing that in advance is worth more than an afternoon of interface experiments. Document the arrangement so the next person does not rediscover it during an incident. A one-line note in the team wiki is enough.