Setting Up a VPN: Which Layer You Put the Tunnel On

Setting up a VPN is not really an installation task. Three decisions come first: which of your traffic you want inside the tunnel, which layer of your setup carries it, and whether traffic stops or continues when the tunnel fails. Installing the software takes minutes. Those three answers are what you live with afterwards.

Start from the traffic, not from the device

Decide who you are moving traffic away from. A tunnel does two separable things. It wraps your traffic so that whoever operates the network you are sitting on cannot read its contents or see where it is going, and it makes the far end see the tunnel’s address instead of the one your connection was handed. Those are two different beneficiaries of one mechanism, and most setup mistakes come from wanting one of them and configuring for the other.

If the party you care about is the operator of a network you do not administer — a shared office, a rented flat, a building’s guest Wi-Fi — the tunnel only has to cover the device you are typing on, and only while you are on that network. If the party you care about is the far end, and you want everything in the building to arrive from one address that is not yours, the tunnel has to sit somewhere every device passes through. If the party you care about is the provider carrying your line, the same is true, and it has to be running whether or not anybody remembered to launch an app.

Answer that before comparing any products. It picks the layer, and the layer decides everything else.

Three layers, three very different reaches

A tunnel can sit inside one application, on one device, or at your network’s edge.

Inside an application. Browser extensions sold as VPNs are generally proxies for that one browser’s traffic. They can change the address a site sees for requests the browser makes, and nothing more — not a second browser, not a mail client, not the operating system’s own connections. That is sometimes exactly what somebody wants, and it is cheap in every sense, but it is not device coverage and should not be described as if it were.

On the device. A client that adds a virtual network interface and takes over the device’s default route covers everything that device sends, including software you had forgotten was running. This is what most people mean by the phrase, and it is the only layer where per-application rules and drop protection can exist, because it is the only layer that knows which program opened which connection.

At the network edge. A tunnel configured on your router covers every device behind it, including devices that will never run a client, and covers them without anyone launching anything. It also cannot tell those devices apart, and it stops at your front door. Putting the tunnel on your router is a commitment rather than a setting.

Plenty of households deliberately end up with two of these. The mistake is ending up with two by accident and tunnelling the same traffic twice.

What the setup actually changed

On any device, three things you can inspect are now different. There is a network interface that was not there before, with an address of its own. The default route — where packets go when nothing more specific applies — now points through that interface. And the resolver the device asks for name lookups has usually been replaced.

The third is the one that goes wrong quietly. A broken route is obvious, because nothing loads. Resolution that carries on using the local network’s resolver looks entirely normal, because pages still load; they load after every name you asked for was sent, in the clear, to a server chosen by somebody else. Learning to read your own network settings lets you see all three states directly on any platform, and it is the single most useful skill in this subject.

Decide now what happens when it drops

Tunnels drop. Laptops sleep, phones move between networks, routers reboot, servers go away for maintenance. The decision worth making in advance is what the device should do in that moment, and there are only two answers: carry on sending traffic over the ordinary connection, or send nothing at all until the tunnel is back.

Failing open is convenient, and it is what happens when nothing has been configured. Failing closed is what people mean by a kill switch, and it belongs to the device layer rather than to tunnels in general — which means choosing the router layer often means choosing to fail open whether that was the intention or not.

Choose on purpose. A tunnel you believe is protecting you while it is not is worse than no tunnel at all, because it changes what you are willing to do on a network you have no reason to trust.

Verify once, from the right place

Check from the device you care about, not from the thing that configured it. A router’s status page reporting a healthy tunnel says nothing about whether a particular laptop’s name lookups are going through it. Confirm the address the internet sees has changed, confirm lookups are going where you meant them to, and confirm both address families are covered rather than just the older one. Do it properly once, then repeat it after anything reboots or updates itself.

Which platform question you actually have

The remaining detail is per-platform, and the part worth knowing is not the menus — those change and are not worth writing down — but what each platform lets a tunnel do.

• Windows exposes the tunnel as an ordinary adapter you can inspect, alongside a built-in client with a fixed feature set; see the adapter, the route, and the resolver.
• macOS funnels essentially every lookup through one system service, which is why name resolution and local devices are where the surprises are.
• iPhone and iPad hand the tunnel to the operating system and rebuild it constantly, so what happens between networks matters more than the install.
• Android is the platform with genuine system-level controls — see the always-on switch and the private DNS setting.
• A Chromebook is several environments in one box, so the question is which of them gets covered.
• A streaming stick may be able to run a client, at a cost worth understanding before you sideload anything.
• A television usually cannot run one at all, which makes it a network problem rather than a device problem.

Once you know which layers you are using, the last piece of planning is arithmetic: how many simultaneous connections your arrangement consumes, which is not the same as how many gadgets you own.