A VPN on a Mac: What Happens to Name Resolution and Local Devices
On a Mac, bringing a tunnel up is rarely the difficult part. What changes noticeably is name resolution, because macOS sends almost every application’s lookups through a single system service that caches answers and can apply different rules to different domains. Two consequences follow: a resolver change applies to the whole machine at once, and the things that break afterwards are usually on your own network rather than out on the internet.
The machine resolves names once, on behalf of everything
Applications on a Mac generally do not talk to a resolver themselves. They ask the system, a system service performs the lookup, and the answer is cached for other applications to reuse. That is true of the browser, the mail client, the software updater, and most of what a Mac runs, with the occasional exception of applications that deliberately bring their own resolution code.
This centralisation is mostly good news. When a VPN configuration installs a resolver, it takes effect everywhere without any per-application configuration, and there is one place to look when something is wrong. It also means the resolver setting is the most consequential single thing a Mac VPN configuration does, and that a mistake in it is a machine-wide mistake rather than an application-specific one.
Stale answers are the classic Mac symptom
The cache does not know your network situation just changed. Bring a tunnel up, and names that were resolved a minute earlier are still resolved — to whatever the previous resolver said, held for as long as that answer’s lifetime allows. So a site that hands out different addresses depending on where the request appears to come from will keep sending you to the old one, and a service that had already been resolved to a nearby edge will keep using it.
The visible version of this is a machine that seems to be half in the tunnel: some things behave as though the tunnel is up, others do not, and toggling the connection changes which. This is not a routing fault, and reconfiguring things will not fix it. It is exactly the situation flushing the resolver cache is for, and knowing that saves a lot of pointless troubleshooting.
What happens to the devices on your own network
Local names are found by a different mechanism, and a tunnel can take it out. Macs locate printers, network drives, and other machines by multicast discovery on the local segment, sometimes combined with a search domain the router hands out. Multicast discovery is confined to the local link by design — it never leaves your network and a tunnel does not carry it — so in principle it should be unaffected.
In practice, two things break it. The first is a configuration that sends every lookup to the tunnel’s resolver, including names only your own router knows about; the tunnel’s resolver has no idea what the machine in your study is called, so those names fail. The second is firewall behaviour that blocks traffic on the underlying interface while the tunnel is up, which also blocks the local discovery traffic that had to stay local.
The signature is unmistakable once you have seen it: the internet works perfectly, and the drive in the next room has disappeared. It is a resolution and filtering problem, not a hardware problem, and it comes back the moment the tunnel goes down.
Split resolution, and why “everything through the tunnel” is not always right
A work configuration and a privacy configuration want opposite things here. A remote-access setup usually wants only the organisation’s internal names resolved by the organisation’s internal resolver, with everything else left alone — a per-domain rule, applied narrowly. A consumer privacy setup wants the reverse: every name resolved through the tunnel, so that nothing about your browsing reaches the local network’s resolver.
Both are legitimate and they are not the same configuration. A Mac can hold both at once, which is how people end up with a machine that resolves one company’s domains through a tunnel that is not running, or sends personal browsing to an employer’s resolver. If a Mac resolves one particular domain strangely and nothing else, look for a per-domain rule left behind by a configuration nobody remembers installing.
The interface list still tells you the truth
A tunnel appears as its own network service with its own address and its own place in the ordering. Whichever service holds the default route is where ordinary traffic goes, and the ordering of services is a setting rather than a law of nature. When a Mac has Wi-Fi, a wired dock, and a tunnel all connected, that ordering is worth actually looking at rather than assuming. The general skill of reading your own network settings applies directly, and on a Mac it also shows you which resolver each service is advertising, which is the fastest way to catch the split-resolution cases above.
What the Mac still says about itself locally
A tunnel changes what leaves your network. It changes very little about what your Mac announces inside it. The machine still has a hostname it broadcasts to the local segment, still advertises services, and still presents a hardware address on the Wi-Fi it is using. Modern Macs may present a different hardware address per network, which is useful against passive tracking between networks — but as address randomisation makes clear, it is a local-network measure with local-network limits, and it is orthogonal to whether a tunnel is running.
Put plainly: on the network you are sitting on, your Mac is still visibly a Mac with a name, and a tunnel does not change that.
Removing a VPN means removing a configuration
Deleting the application is not the same as deleting what it installed. A VPN configuration is an object the system holds, and it can outlive the software that created it — leaving an entry that looks connectable with nothing behind it. The parts worth checking after removal are whether a configuration still exists, and whether any per-domain resolver rules are still in force. If a Mac keeps resolving something oddly long after the VPN is gone, that is usually where it is coming from, and no amount of reinstalling the app will find it.
None of this is a reason to prefer or avoid the platform. It is a reason to treat the resolver, rather than the route, as the thing to verify first on a Mac — which is the opposite of the instinct most people arrive with. If you have not yet settled which layer should be carrying the tunnel, that decision changes how much of this applies.