What the Local Network Still Sees Through Your VPN

Three observers get folded into one question whenever somebody asks whether a VPN hides their traffic: the network they are attached to, the machine in their hands, and the operator of the tunnel. Each learns something different, and the tunnel changes each of those views in a different way. It helps to work the other direction and start from the claim being made, because a claim is the thing that has to survive scrutiny. Decide which claim you need, then compare tools against it.

Claim One: Nobody Can Read the Traffic

Begin with the narrowest claim: the payload stays unreadable. A passive observer on the path cannot see inside a TLS session, so the tunnel adds little to a site that already uses HTTPS, and it adds nothing against the two endpoints. The party that breaks this claim is whoever controls the device, because an inspection proxy terminates the connection and re-signs it with a root the machine already trusts. That is why the padlock still appears while the certificate chain carries the name of the organisation that installed the root.

security find-certificate -a -p /Library/Keychains/System.keychain | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -noout -print_certs | grep subject
certutil -store Root

On macOS that pipeline prints one subject line for each certificate in the machine keychain, without opening a window; on Windows, certutil -store Root lists the same store that certlm.msc shows graphically. A root belonging to a school, an employer, or a network security product is the entry to look for. Finding one proves only that interception is possible, not that it is happening.

What you may do about it is a policy question rather than a technical one. Removing a profile or an inspection root from hardware you do not own normally breaches the acceptable-use agreement, and the management system tends to notice and re-apply it, so a requirement that the device owner must not read your traffic needs a different device rather than a different setting.

Claim Two: Nobody Can See Where You Go

Destination is the harder claim, because two disclosures happen before a page loads. A lookup goes to whichever resolver the system is configured to use, and the answer is visible to the network carrying it. A TLS handshake then carries the requested server name in the clear unless Encrypted Client Hello is supported at both ends. Neither disclosure involves decryption, so the tunnel has no effect on either.

resolvectl status | grep -A2 "Link"
nslookup example.com

Which resolver is actually in use decides the exposure, and it can be measured instead of argued about. On Linux, resolvectl status prints the DNS servers per link, and its output tells you whether the site resolver or the pushed one is answering. Windows answers the same question with nslookup example.com, whose first block of output is the DNS server that answered.

When the laptop queries the site resolver before the tunnel comes up, or the profile arrives without a replacement server so the old one stays in use, the administrator still collects hostnames without decrypting anything. Encrypted DNS in the browser either sidesteps the pushed resolver or gets blocked outright and fails closed. The exit operator sees the same names from its side. Changing the resolver therefore does not move that disclosure away from the tunnel provider.

Claim Three: Nobody Knows You Connected

The third claim is the one a tunnel cannot support, because the packets still cross the local network. That network learns the endpoint address, the approximate volume, the timing, and the existence of one long-lived encrypted session, which is enough to block, throttle, or simply notice. A firewall that cannot read a packet can still refuse to pass it. Being watched is not the same as being watched by nobody: you moved the observer, you did not delete it.

Split tunnelling, and any application that ignores the pushed route, produce flows outside the tunnel that look exactly as they did before. Those are the flows a careful observer notices first, and the client route table shows which destinations are excluded.

The operator at the other end holds the mirror image of that view: exit address, timing, volume, and usually the site names. Your provider becomes the party with the vantage point, which is a different bargain from invisibility. Picking a provider you trust is a real decision; calling the result unobserved is not.

Decide Which Claim You Need

Write the requirement down in one line before touching a client: hide the content, hide the destinations, or hide whether you connected at all. Content is already handled by HTTPS plus the tunnel, while destinations require a resolver and a path that bypass the site equipment entirely.

The third requirement is the awkward one, because something is still visibly connected somewhere, encrypted or not. No client setting changes that. If the requirement and the policy pull apart, that gap belongs in a conversation with whoever owns the policy, not in a client option. The person who can answer it is the one who wrote the policy.