Phone Left Out of the VPN? Router Tunnel vs Client per Device

The laptop is connected to the VPN, the phone is on the same Wi-Fi, and the phone is still browsing from the ISP address. That is not a client bug: a tunnel lives on the machine that terminates it, and nothing else inherits it by proximity. Coverage only spreads when the router itself runs the client, or when a machine is deliberately turned into a gateway for the LAN. Which model you want is decided by three things, the protocol your provider actually speaks, how differently the devices need to be treated, and which failure you can live with at nine in the evening.

What a router tunnel actually covers

When the tunnel terminates on the router, every device that routes through it shares the exit. That is the appeal for a television, a console or an appliance that will never run a client: nothing to install, nothing to keep updated, and one place to change providers.

The coverage is conditional in ways that surprise people. A guest network or a second SSID with its own policy takes the path that policy defines, not the tunnel. An IPv6 path can bypass a tunnel that only carries IPv4. A device running its own VPN app, or its own encrypted resolver, ignores the router completely. And the router's own traffic, updates and DNS included, follows its output policy, which is a different path from the forwarded traffic of the LAN.

Verification is the same in both models and takes a minute: ask two devices what address the world sees, then check the router's connection list for the tunnel. If the phone reports the ISP address while the router shows an established tunnel, the phone is not being routed through it, and no amount of reconnecting will change that.

Where a client per device wins

Per-device clients win as soon as requirements diverge. A work laptop may need a corporate tunnel that the phone must not join; a provider client may offer split tunnelling per application, which a router cannot express; a console may need to stay outside to keep its NAT type. Each device also fails on its own, so one expired subscription does not silence the whole house.

Credentials are the sharper argument. A router that connects on behalf of everyone holds one account, and every person on that network inherits its access. If the intent is per-person authentication before internet access, a router tunnel alone cannot do it. The usual design is a captive portal that validates the account and then releases the client into an already-established tunnel, which is more moving parts than most homes want.

Protocol support decides more cases than preference

Consumer routers expose only the protocols the vendor shipped. A router offering PPTP, L2TP or plain IPsec cannot connect to a provider that publishes only OpenVPN or WireGuard profiles, and no amount of configuration changes that. The honest options are a provider that speaks a supported protocol, a router running OpenWrt or another firmware with the client you need, or a client on each device.

The reverse case is just as common: an OpenVPN-capable router cannot use a provider whose service depends on a proprietary client and its own routing tricks. Read the provider's supported-protocol page before buying hardware, and check the firmware version, because "supports WireGuard" on a product page often means one specific firmware generation.

A travel router with a WireGuard client is the cheap version of the router model, and it is a reasonable answer for a handful of devices that cannot run a client. It is still a router tunnel, so everything above about guest networks, IPv6 and shared failure applies to it unchanged.

The third option: a machine as the gateway

Sharing a client from a laptop is possible, and it is what people usually mean by turning the laptop into a router. Enable forwarding, add a source-NAT rule for the LAN, then point the other devices' default gateway at that machine:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

It works until the machine sleeps, the client reconnects into a different profile, or the machine's own firewall drops forwarded packets. Then everything behind it loses connectivity at once, and the failure looks like a dead network rather than a VPN problem.

For a lab or a temporary setup it is fine. As a permanent arrangement it makes one laptop the single point of failure for a household, and it usually ends with someone wondering why the television stopped working when a lid closed.

Inbound ports, DNS and the failure you share

Inbound services move with the tunnel. A router VPN usually breaks port forwarding for a LAN server, and a dynamic DNS name has to point at the VPN exit rather than at the ISP address if the service is meant to be reachable through the tunnel. Some providers do not offer a routable inbound address at all, which quietly ends any plan that depended on one.

DNS follows the router when the router owns the tunnel, which is convenient until one device needs a different resolver. A client per device can express that; a router policy cannot without splitting the network in two. Failure is shared as well, because one crash, one expired subscription or one bad pushed route disconnects every device at the same moment.

Choose the router model when the devices cannot run clients and a single exit is acceptable. Choose clients per device when policies differ, when the provider needs a protocol the router lacks, or when the account must not be shared. If a machine is the gateway, write down which interface shares which network and test the tunnel-down case, because that is the state in which most of these designs turn out to be wrong.