OpenVPN engine or Tunnelblick: who owns the Mac VPN session?

Homebrew installs an OpenVPN program; Tunnelblick installs a manager that runs one or more engines. Those are different layers, and the useful question is not whether you like using a terminal. It is who owns the configuration, the DNS changes, the credential prompt and the cleanup when the session ends. A single owner for those layers is what makes the setup predictable.

Work through the five checks below in order. The first one that has two owners is the one that produces the strange half-connected states people blame on OpenVPN itself. Each check names the evidence that settles it.

Check one: which OpenVPN binary actually runs

Run pgrep -fl openvpn while connected and read the full command line. The first path is the engine that is actually running. On Apple Silicon a Homebrew install usually lives under /opt/homebrew, while Intel Macs use /usr/local, and Tunnelblick runs an engine from inside its own application bundle.

Tunnelblick bundles engines and lets a configuration select one. Updating the Homebrew formula changes the standalone binary, not the engine a Tunnelblick profile launches. If you compare versions to explain a behavior difference, compare the engine in the process list rather than the one in the package manager. The version string alone will not tell you which profile that engine loaded.

A copied profile can also make two engines look identical while they read different files. The profile path in the command line tells you which configuration the running process loaded; a profile open in an editor is not evidence. Compare that path before comparing behavior.

Check two: who changes DNS and routes

The engine can run OpenVPN's own up and down directives, but the manager may own the same lifecycle. Tunnelblick's nameserver settings control its standard connection and disconnection scripts, and when that integration is enabled, competing directives in the profile can be ignored.

That matters because DNS is where a working tunnel most often looks broken. Check scutil --dns while connected, note which resolver is first, and confirm it returns after disconnect. If the profile expects to set DNS itself while the manager also manages it, one of the two will lose.

Decide which layer owns DNS before the first connect, then remove the losing directives rather than leaving both in place. Route changes follow the same rule: one owner, visible in the configuration, with a documented restore path.

Check three: where credentials come from

An interactive prompt and an unattended process have different requirements. A credential saved by one application is not automatically available to another process, and a keychain item scoped to the manager may be invisible to a standalone engine started from a shell.

List the credential source for the profile: a client certificate and key, a username and password prompt, or a token supplied by an external helper. Then confirm the chosen owner can reach that source without a human present if the connection is supposed to survive a reboot.

Check four: who starts, supervises and stops the process

A standalone deployment needs a supervisor if it is meant to stay up. Launchd can start the engine at login or on demand, restart it after a crash and stop it cleanly, but someone has to write and own that job. Running the command in a terminal works for a test and not for a user who closes the window.

If Tunnelblick remains the owner, use its supported controls instead of starting a second engine. The Homebrew binary, given a copied profile, launches an independent connection with its own configuration and integration context rather than commanding the existing Tunnelblick session.

Whichever owner you choose, define what happens on sleep, network change and logout. A manager normally handles those events; a bare process usually does not, and the resulting stale route or resolver is easy to misread as a server fault.

Check five: how the handover is verified

Test the new owner with the old one disabled, then test the old owner again if you plan to keep it. A private resource that answers under one workflow and not the other is evidence about the missing integration, not about the server.

For a handover to a standalone engine, record the profile path, the binary path, the supervisor, the DNS owner and the credential source. Then verify the private resource, the public internet path and a clean disconnect in that order. If DNS or routes remain after disconnect, the new owner is not finished.

For a handover to Tunnelblick, select the engine for the configuration, enable the DNS integration you intend and remove profile directives that fight it. Then repeat the same three checks. A connection that works but leaves the resolver changed is a failed handover, even if the tunnel came up.

Packaging does not settle server compatibility. Check the service's own client requirements, and pick the engine alone only when you intend to supply its management.