A VPN on a Chromebook: Which of the Three Layers Gets Covered

A Chromebook is not one environment. It runs ChromeOS and the browser, it can run Android apps inside a container, and it can run a Linux environment inside another one. A VPN installed in one of those does not automatically cover the other two. So the setup question on this platform is not how to install anything — it is which of the three environments your tunnel actually reaches, and that is a question you answer by testing rather than by reading a product page.

Each of the three has its own path to the network, and they are not equally visible to each other. The browser and ChromeOS itself are the base system. The Android runtime is a container with its own notion of networking, running apps written for a different platform. The Linux environment is a separate container again, with its own resolver configuration and its own view of the machine’s addresses.

That layering is what makes Chromebooks pleasant to use and awkward to reason about. Traffic from a browser tab, traffic from an Android app, and traffic from a command run in the Linux container may leave the device by three different routes, and a tunnel established in one container is not obliged to capture the others.

A browser extension covers tabs and nothing else

Extensions sold as VPNs on this platform are proxies for the browser’s own requests. They can change the address a website sees for traffic that browser generates. They do not cover an Android app, they do not cover the Linux container, and they do not cover the operating system’s own connections.

There is nothing dishonest about that as long as it is what you wanted. On a device where most of what you do genuinely happens in tabs, it may be sufficient. It is simply not device coverage, and on a Chromebook the gap between “the browser” and “the device” is wider than on a laptop, because there are two whole containers sitting outside the browser.

An Android VPN app covers what Android can see

This is the case that needs testing rather than assuming. Installing an Android VPN app on a Chromebook creates a tunnel using the Android platform’s own mechanism, inside the Android container. Whether that tunnel also captures browser traffic and ChromeOS traffic depends on how the platform wires the container’s networking into the host, and that is a platform implementation detail rather than something the app controls or advertises.

The test is short and it is the single most valuable thing you can do on this platform. With the tunnel up, check the address the internet sees from a browser tab. Then check it from inside the Linux container. Then, if you can, from an Android app. If the answers differ, you now know exactly which environments are covered, and you know it as a fact rather than an assumption. That is the whole method: check whether the tunnel is actually carrying your traffic, separately, per environment.

Doing this once is worth more than any amount of comparing clients, because the answer is a property of your device and its configuration rather than of the client you chose.

The Linux container resolves names on its own terms

A container can have its own resolver configuration, and often does. This is why a name can resolve one way in a browser tab and another way at a shell prompt on the same machine at the same time — not a fault, just two environments asking two different resolvers.

For anyone using the Linux environment for real work, that is worth knowing before it produces a confusing afternoon. It also means a tunnel that changes the resolver for the base system has not necessarily changed it inside the container, so lookups from your development work may be going somewhere you did not intend even while the traffic itself is tunnelled. The general habit of reading your own network settings applies here, with the twist that you have to read them in each environment rather than once.

ChromeOS’s own VPN configuration

Like every operating system’s built-in client, it implements a fixed set of connection types and expects to be handed details. That makes it the right path for connecting to an organisation’s remote-access service, where somebody gives you a server address, a credential, and possibly a certificate. It is a device-level configuration, so it sits below the containers rather than inside one, which is a point in its favour when it supports what you need to connect to.

What it is not is a substitute for a consumer client’s features. There is no per-application routing and no fail-closed enforcement in a built-in client of this kind, on any platform.

The managed-device case, which is most Chromebooks

Many Chromebooks belong to a school or an employer, and on those the network configuration may not be yours to change. An administrator can define network and VPN configuration by policy, prevent users from altering it, and require traffic to take a particular path. On such a device the honest answer to “how do I set up a VPN” is often that you cannot, and that attempting to work around it is a policy question about the device you have been lent rather than a technical problem to solve.

It is also worth being clear-eyed about what a managed device already does. If an organisation controls the device’s configuration, it may also be inspecting its traffic, and a personal tunnel installed on top of that is not a way to become invisible to the party that administers the machine. Whether any of that is acceptable is between you and whoever gave you the device; it is not something a VPN changes.

What to do, in order

Work out which environments you actually use. Cover the base system if you can, since that is the layer everything else sits on. Then test from each environment separately and write down which are covered, because that list is the real answer for your machine. And if the device is managed, stop and ask before configuring anything. The broader question of which layer should carry the tunnel has an extra wrinkle here: on a Chromebook, “the device” is three places at once. It is also why some people with a Chromebook and appliances end up putting the tunnel on the network instead, alongside the way Android’s own controls work on the container inside.