What a Mac VPN export contains, and what it leaves behind
A Mac VPN export carries settings and sometimes a private key, but not the keychain password or the device enrollment. Check each part first.
Click Export in a Mac VPN client and you end up with a file that describes a connection without being one. Server address, port, protocol and often the certificates sit inside it. The login password, the passphrase on a private key and the enrollment that authorizes this particular Mac usually do not. That is why a profile can import cleanly, appear in the client list, and still fail at the first authentication prompt; the gap is a property of the format, not a corrupted download.
| Part of the connection | Where it lives on the old Mac | What an export does with it |
|---|---|---|
| Server, port, protocol, routes | Client profile or managed settings | Usually included when the client exports configuration |
| Client certificate and private key | Inside the package, the login keychain, or issued by MDM | Included only if the format packs it; a keychain-held key stays behind |
| Login password, key passphrase | Login keychain | Left out by design |
| Device authorization or enrollment | Server side, bound to the certificate or the device record | Not transferable; the new device has to enroll |
What the exported file actually contains
An export is a container, and the file extension tells you less than the contents do. OpenVPN profiles are text: directives, plus optional inline <ca>, <cert> and <key> blocks. Tunnelblick setups are compressed archives of configurations and settings. A managed .mobileconfig is a plist of payloads. Two listings answer most of the question before you import anything.
For a text profile, count the PEM blocks it carries: grep -c "PRIVATE KEY" your-profile.ovpn. A non-zero result means the file holds key material and has to be handled like a password from that point on. For an archive, list it without extracting: tar -tf export.tbz, or unzip -l export.zip if the client produced a zip. Key files, certificate files and up or down scripts in that listing are the parts that re-issuing a user account will not recreate.
The opposite case matters as much. When the profile points at a key by filename instead of embedding it, the export is incomplete on purpose and the missing half has to come from whoever issued it. Copying that file alongside is fine when you own the certificate authority; it is not fine when the file came with a device-bound certificate that was generated on the old Mac.
Why the keychain half never travels
macOS keeps VPN passwords and key passphrases in the login keychain, and clients store them there rather than in their own settings files. Tunnelblick says so in its export and import guide: the setup archive carries configurations and settings and leaves out the usernames, passwords and passphrases held in the keychain. The omission is deliberate. Keychain items are protected per user and per machine, so a copied item has no valid access control on the destination, which leaves either a useless file or a plaintext secret.
You can confirm where the credential lives before planning the move. security find-internet-password -s vpn.example.com prints attributes for a matching item and exits non-zero when there is none; the same command with -g would prompt to reveal the password, which is why the query without it is the safer check. A hit there means the profile is not carrying the password and cannot be made to. It also means the password will be requested again on the new Mac, and an Always Allow grant on the old one counts for nothing there.
Not every secret is a keychain item, though. Tunnelblick's own package documentation notes that a package may contain key, certificate and script files. So the export excluding keychain entries is not the same claim as the export being safe to email; treat the archive as sensitive until you have listed what is in it.
Native and managed VPNs have no export path
Connections configured through System Settings do not offer a supported export. scutil --nc list shows the services the system knows about, and scutil --nc show "Work VPN" prints one service's configuration, enough to read its server and protocol. Neither is a migration tool. The service identifiers stored in /Library/Preferences/SystemConfiguration/preferences.plist are references into that file, so copying the file and rewriting identifiers is not a supported transfer and can disturb unrelated network services on the destination.
The supported route is the one Apple documents: install an administrator-supplied VPN settings file, or enter the settings the operator gives you. When the connection is managed, ask for a fresh file or a fresh enrollment instead of rebuilding it from a screenshot of the old dialog. For a profile pushed by MDM, the certificate payload may carry the identity while the private key is generated on the device, and in that case even a flawless copy of the old profile cannot authenticate the new Mac.
Verify the restore instead of trusting the list
A profile in the list and a working tunnel are two different states, and only one of them is worth reporting. After importing and connecting, check that the tunnel interface exists, then check what the tunnel is doing.
ifconfig | grep -A3 utun shows the tunnel interface and its addresses. scutil --dns | grep nameserver shows which resolvers are active after the connection, which is where split-DNS profiles usually diverge. Then reach the resource that actually matters: curl -sS -o /dev/null -w "%{http_code}" https://intranet.example.com. All three passing means settings, DNS and routes arrived; a green icon in the client means none of that on its own.
Two failures show up often after an import and both get blamed on the file. Public names resolving while internal ones do not usually means the profile's DNS servers were dropped or split-DNS was not preserved. A tunnel that comes up and passes no traffic usually means routes or server-side authorization did not follow the profile. Re-importing the same archive reproduces both.
Before you retire the old Mac
Deleting the export is not revocation. If the old device authenticated with a certificate, the server still trusts that certificate until it is revoked or reissued. If it authenticated with a shared account, sessions on that account may still be live. Do the server-side step while the hardware is still in front of you.
Store the new profile with your other credentials when it contains a key, and type the password into the client so it lands in the new keychain rather than in a file. Last check: connect from the replacement with the old Mac powered off. A handoff that only works while the source machine is online was never a complete one.