How to test a second VPN client on a Mac without losing the first

You install the second client to compare it, and the first one stops working. Nothing was deleted, and both applications are still installed. What changed is underneath them: a system extension, a DNS setting or a default route, and the two clients now disagree about who owns it. Installations are not the risky part; the risky part is running both without a recorded baseline to return to.

The symptom: the working setup stops after the second install

Modern macOS VPN clients frequently ship a network extension rather than an old-style interface. Installing one can prompt for approval, add a configuration profile, or register a system extension that influences traffic before any connection is made. The extension loads before the app window appears, which is why the original client can fail while the new one sits idle.

If the original client then fails to connect, or connects and resolves nothing, the new extension is the first suspect. That is not proof of a conflict, but it is where the investigation starts. Check the extension list and the installed configuration profiles next, not only the applications folder.

Record the baseline before installing anything

Write down what currently works: the application result, the client version, the endpoint it connects to, and any per-app or split-tunnel exclusions. Save the original profile through the protected process the client supports, not by copying files out of an application bundle.

scutil --dns | head -40
netstat -rn | head -30
ifconfig | grep -E "^(utun|ipsec)"

Capture those three outputs while the working client is connected. They give you the resolver state, the route table and the interface list that a working setup produces, which is exactly what you need to compare against later. If the Mac is managed by an employer, confirm the comparison is allowed before you start, because an automatic work connection can reactivate while you test and the result then represents neither client alone. Store the three outputs beside the profile note so the later comparison has a reference.

Change one active path at a time

Stop the original connection with its normal control, then start the alternative. Two connected clients at once produce a result that describes the combination, not either product. Keep the endpoint and the task comparable if the services allow it, because a faster download through a different server compares two connection options rather than two applications.

If the new client fails, preserve its first error before you change anything else. The first error usually names the stage, and a second attempt after a settings change often reports something less useful.

Compare DNS, routes and the app, not just speed

Run the same three commands with the new client connected and compare them line by line. A resolver that points somewhere else, or a route table missing the private subnet, explains most differences in behaviour before you look at throughput. Then test the actual application with the same task, since a client that connects quickly and fails to resolve an internal name has not won the comparison even if the status window looks better.

Note which interface the traffic used. On macOS the tunnel interface name is not a reliable indicator of which client owns the route, so pair the interface list with the route table rather than reading either alone. If two utun interfaces exist, the one carrying your traffic is the one with a matching route and a resolver entry. Guessing from the name is how the wrong interface gets blamed, because the interface that exists is not always the one carrying traffic.

Read the three outputs instead of skimming them. In the resolver dump, a name server attached to a utun interface shows which client installed it; in the route table, the default route names the interface that carries traffic; in the interface list, a second utun device means a second tunnel was created. Those three lines, compared with the baseline, separate a recovered setup from one where both clients still compete.

Restore, then remove cleanly

Return through the original client's own workflow and confirm the baseline outputs match what you recorded. If the resolver or route table does not recover, stop and fix that before removing anything else. Remove the unused setup through the component that owns it: the client uninstaller, the profile, or the system extension settings.

Finish by updating your notes with the version you tested, the endpoint you used, and the result for each. Six months later that record is the difference between a decision and a rumour.