An Untrusted VPN Is Three Separate Boundaries, Not One

"I do not trust this VPN" is usually three statements wearing one sentence. The remote peers on that network might reach services on your host, the operator running the tunnel might observe traffic that passes through it, and the client software you installed might be able to change your machine's network policy. The belief worth correcting is that a firewall rule, a virtual machine or a careful operating-system choice answers all three. Each measure answers exactly one of them.

The myth: one control covers the whole risk

The common assumption is that joining an untrusted network is a single decision with a single mitigation. People pick the control they already trust, apply it, and consider the risk retired: the firewall is on, the workspace is disposable, the client came from a reputable vendor.

Those controls do not overlap the way the assumption implies. A host firewall constrains what a remote peer can reach, and it does nothing about an operator who terminates your TLS. A virtual machine separates a workspace from your host files, and it does nothing about a client component allowed to reconfigure the network stack underneath both. Naming the boundary each control actually creates is the whole exercise.

Separating them also tells you which risk you have chosen to accept. Most real decisions mitigate one boundary and tolerate another, which is fine as long as the change record says which is which.

What the remote peer can actually reach

Start with listening services. A tunnel interface treated as broadly trusted because its packets arrived encrypted is the usual mistake, and it turns every local listener into a candidate target for whoever else sits on that network. Encryption protects the wire between two endpoints; it says nothing about the intent of the peer at the other end.

ss -tulpn
sudo nft list ruleset
ip -br addr

Bind services to the address that needs them rather than to every interface, and permit only the operations the approved task requires. Keep forwarding, bridging and application proxying explicit, because two network attachments do not create a transit path by themselves but a proxy rule certainly can.

An approved disposable workspace reduces what the remote network can reach, but only when its sharing configuration matches the claim. Shared folders, clipboard integration, credential agents and management channels all cross the boundary that the workspace was supposed to create. A workspace label proves nothing about which of those are open.

NIST's zero-trust architecture states the principle behind all of this: network location alone does not grant implicit trust. Resource authentication still has a job after the tunnel is admitted, and so does the question of who else shares that network.

What the operator in the path can see

A VPN moves your traffic to a different place on the path; it does not add application encryption. If the provider terminates your TLS, the provider can read what your browser would otherwise have protected, and no local firewall rule changes that.

Keep normal certificate validation for the real destination and understand the resolver and metadata path, because a DNS query can reveal more than the payload it precedes. Metadata alone, meaning which addresses you contacted and when, often answers the question the operator was asking without any need to read content. That is why "the traffic is encrypted" and "the traffic is private" are different claims.

If that visibility is unacceptable for the task, the answer is a different approved architecture rather than more local filtering. Local filtering cannot remove an observer from a path it still sits on.

What the local client is allowed to change

This is the boundary people miss, and it is the one that makes the other two moot. On Linux, CAP_NET_ADMIN covers interface configuration, firewall administration and route changes within its network context. Software holding that capability can rewrite the policy you just wrote.

getcap /usr/sbin/openvpn
systemd-analyze security vpn-client.service
ip netns list

A network namespace is a real boundary for network state and a poor one for everything else: it does not isolate the filesystem or the credential store. Treat it as one layer rather than as a container for the whole problem.

Obtain the client and its configuration from a maintained source, review the authority it requests, and keep privileged components under administrator control. A virtual machine can form part of a qualified evaluation boundary without becoming permission to run an unexplained installer beside valuable credentials. The installer runs with whatever authority you grant it, and that authority is the boundary.

Write down which boundary you accepted

Finish with a sentence that names four things: the trusted local code, the permitted remote access, the protected application data, and the operator relationship that remains. That sentence is worth more than a blanket claim that a VM, an operating system or an antivirus product made a hostile network safe.

Then confirm the narrow operation works and the required denial still holds, including after the tunnel drops. A boundary that only exists while the tunnel is up is not the boundary you documented.

No test proves that every vulnerability is absent, and a review claiming otherwise is overclaiming. The honest output names the residual risk and the person who accepted it.