Mobile data and campus Wi-Fi: what a VPN actually adds

Ask who is watching before asking whether a tunnel helps, because the answer changes completely with the observer. On mobile data the interesting observer is the carrier; on campus Wi-Fi it is the network you just joined. Those are different positions with different visibility, and one tunnel cannot improve both in the same way. Most of the confusion comes from treating a VPN as a property of the device instead of a change in who can see what. Walk the hops one at a time and the decision usually makes itself.

What the radio hop does and does not hide

Radio encryption has a poor record in its early generations, and its later ones are stronger without becoming invisible. The GSM A5 family was broken years ago, and the third-generation algorithms have published practical attacks. What survives all of it is metadata: which cell, when, how much, and which addresses. Route traffic through a tunnel and the carrier loses the destinations while the tunnel operator gains them, a trade worth making against a curious carrier and worthless against one that keeps and sells records.

The operator is also not the only party on that path: a roaming agreement adds another network that can observe the same metadata, and the tunnel's exit becomes the place where all of it collects.

HTTPS already covers most of it

Almost everything people do on a phone is already inside TLS: webmail, banking, messaging, most applications. A tunnel does not strengthen that, and when it supplies the resolver it can see names that TLS would otherwise have concealed. What TLS leaves outside is the destination pattern, any legacy plaintext protocol, and the timing and volume of the conversation.

That residue is exactly what a VPN changes, which is why it matters more on a shared Wi-Fi link than on a link already encrypted per hop. It is also why a bank site over mobile data does not need a tunnel: the certificate and the client already address that threat.

The campus VPN is an access tool

Universities run a VPN to place you inside their own network, and that is the correct answer for a licensed journal, a department share, a lab machine or a service the perimeter blocks. It is not a privacy tool, and a full tunnel makes the university the observer of everything you do, including sites that have nothing to do with coursework. When the goal is to keep the campus from seeing your destinations, using the campus VPN is precisely backwards.

The acceptable-use policy belongs to the mechanism rather than to the footnotes. Reaching a licensed resource through the campus tunnel is what it is for; using a commercial tunnel to bypass a campus filter is usually a violation whether or not it works. Those two sentences settle most real cases without any opinion about vendors.

Decide with three questions

Three questions remain: who is the observer you care about, what is already encrypted end to end, and what the policy allows. Answer them in writing, because the answers are short and they are the part that later changes.

Then choose the shape of the tunnel from those answers rather than from habit. If one tunnel is for private resources and another instinct is for ordinary browsing, keep them separate rather than asking one client to do both badly. Split tunnelling is a legitimate design rather than a compromise, as long as the routing is written down and you know which traffic takes which path. The failure to avoid is the client that reports connected while sending only selected prefixes, with nobody noticing which case they are in.

Test both paths, then describe them honestly

After connecting, test one private resource and one ordinary website, and observe the exit address at each end. That single test separates a working split tunnel from a full tunnel, and it is the only coverage claim you can make without guessing.

Write the two results into the ticket. A sentence like that is worth more than any statement about whether the VPN is worth it, because it names the paths instead of the product.