What really changes when you switch saved VPN configs on macOS
Switching a saved Mac VPN is not a profile swap. See what changes in routes, DNS and credentials, and how to verify the tunnel you actually got.
You open the VPN list, choose the other saved entry, and expect a clean swap: a new exit address and everything else unchanged. That is the assumption to drop first. On macOS a saved VPN is a full network service rather than a preset, so switching services can change routing, DNS and authentication at the same time. The menu bar tells you which service is active; it does not tell you whether the tunnel underneath matches what you intended.
The saved list is not a profile picker
Each entry in System Settings > Network is its own service, with its own server address, account, authentication method, DNS servers and options such as Send all traffic over VPN connection. System Preferences holds the same list on older releases. Two entries can point at the same hostname and still behave differently, because the protocol or the client extension decides how the tunnel is built.
Third-party clients keep separate lists. Tunnelblick reads configurations from its own folder, WireGuard keeps its own tunnel list, and OpenVPN Connect stores profiles inside the app. Some register a configuration with the system; others keep everything inside the app and never appear in the built-in list. "Switch to the saved one" therefore means different actions depending on which app owns the profile.
scutil --nc list prints the VPN services registered with the system configuration, with quoted names. Use those exact names when you script a switch, and do not assume the list covers every third-party tunnel.
What a switch actually changes
Four things move together when the active service changes. The default route follows the new tunnel if that service sends all traffic; the resolver list changes to the DNS servers the service specifies; new connections take the new tunnel address as their source; and the credentials in play belong to the new service. A native configuration and an app profile are not interchangeable, even when both terminate at the same gateway.
| What you assume | What the system does |
|---|---|
| Same server name means same tunnel | Protocol, certificate and account are per service |
| All traffic follows the active VPN | Only when Send all traffic over VPN is on |
| DNS switches with the VPN | Only if that service defines DNS servers |
| Disconnect ends the connection | On Demand or a management profile can reconnect |
| Open sessions survive the switch | TCP sessions tied to the old address stall |
The DNS part catches people out. macOS maintains a resolver order, and scutil --dns shows which resolvers are in use and on which interface. A VPN service with no DNS servers configured can leave the Wi-Fi resolver answering, so you get a new public address with the old DNS behaviour and conclude the switch half-worked.
Why the old configuration keeps coming back
If you disconnect and the same service reconnects a moment later, look at On Demand before anything else. A Connect on demand rule can bring a service back when an app resolves a matching domain, and a management profile can enforce the same rule. Deleting the entry rarely fixes it: a profile-installed configuration usually returns at the next profile refresh, and a manual one can leave its password behind in Keychain while the service is gone.
Starting a second service does not always stop the first. Depending on the client and protocol you may end up with two tunnels and two sets of routes, and service order plus route specificity decide which one carries traffic, not the icon you clicked last. Check the interfaces before you assume a swap happened.
Verify the tunnel, not the checkmark
Work through the system's own view before you touch settings. scutil --nc status "Name" reports what the system believes; ifconfig shows whether a utun interface has an address; netstat -rn -f inet shows where the default route points; scutil --dns shows the resolver actually in use. Then open a fresh connection and confirm the exit address, because a page that was already signed in may still be using a socket bound to the old tunnel.
If DNS still answers from the local network, compare the service's configured servers with the resolver list. If the default route still points at the physical interface, the service is split-tunnel or not fully connected. Both are configuration results, not proof of a broken client.
A switch order that avoids surprises
- Note the current service and whether a profile manages it.
- Disconnect it first when the two tunnels cannot coexist.
- Connect the target and wait for Connected, not Connecting.
- Check the default route, the resolver list and a fresh exit address.
- Restart apps that hold long-lived sessions.
Keep the old entry until the new one passes those checks, and give every entry a distinct name; identical labels make the next failure harder to attribute. Apple's Mac Help describes the native side at Set up a VPN connection on Mac, which is the reference to check before editing a managed configuration.
If the selection reverts, treat it as policy or On Demand first. Confirm who owns the configuration and whether it is set to connect automatically, then decide whether you are switching a service or fighting a profile.