Which protocol is behind that saved Mac VPN profile?

Somebody names a Mac connection "Office VPN", the label survives two server migrations, and everyone keeps calling it the office VPN long after the protocol changed. The name is a nickname stored beside the configuration; it is not evidence of what the Mac negotiates. Reading the declared type takes one field, and separating that stored type from a live session takes one more step. Here is the order that avoids guessing.

The label is a nickname, the payload declares the type

A macOS VPN service is a system configuration entry with a display name, an owning client and a set of typed settings. The display name is free text, editable by whoever created the entry, and it is the part users see in the menu bar. The settings carry the facts: which connection type, which gateway, which authentication arrangement. Nothing keeps the two in sync, which is why a profile called "L2TP office" can be an IKEv2 service.

For a personally created connection, the owning application or the system's own VPN panel shows those settings. For a managed Mac, the profile belongs to the administrator, and the right move is to request a non-secret summary rather than editing a managed payload. The two cases look similar in the menu bar and behave nothing alike underneath. One is yours to inspect and change; the other is deployed and will be restored on the next check-in.

That distinction matters because managed and personal configurations are governed differently. A profile installed by management will be replaced or re-applied, so a local edit either fails or silently reverts. Ask the owner for the type, gateway identity and authentication method instead of reverse-engineering a file you do not control.

Read VPNType before anything else in the payload

Apple's managed VPN payload schema declares its connection type in the VPNType key, inside a dictionary whose PayloadType is com.apple.vpn.managed. The value is a short token such as IKEv2, IPsec, L2TP or VPN, and everything else in the payload is interpreted according to that token.

<key>PayloadType</key>
<string>com.apple.vpn.managed</string>
<key>VPNType</key>
<string>IKEv2</string>
<key>IKEv2</key>
<dict>
  <key>RemoteAddress</key>
  <string>vpn.head-office.example</string>
  <key>RemoteIdentifier</key>
  <string>ikev2.head-office.example</string>
</dict>

This fragment is illustrative rather than installable: it is one entry of a payload array, stripped of the profile metadata and credentials a real deployment needs. Read it for shape, not for content. Note also that RemoteAddress and RemoteIdentifier are different fields with different jobs, even when a deployment gives them the same string.

A legacy value such as PPTP may still appear in an old file without being a choice current macOS offers for a new configuration. Finding a token in a stored profile proves what was written, not what the operating system will still accept.

Custom types need VPNSubType and the owning app

When VPNType is VPN, the payload must also carry VPNSubType, which identifies the plug-in or Network Extension provider that implements the connection. That identifier is what routes the connection to a specific client, so a wrong subtype produces a profile that installs and then refuses to start.

For app-extension based providers the identifier belongs to the containing app rather than to a guessed extension name, which is the detail people usually get wrong when hand-editing a profile. Even a correct subtype describes the client, not the wire protocol, the authentication method or the remote-access policy that client will use.

So a custom payload tells you which software owns the connection and little else. To learn what it negotiates, read that provider's own documentation and its configured settings. Copying a subtype from another organization's profile is not a configuration technique; it is a guess that happens to parse.

List what the Mac has actually configured

Before reading any file, ask the system what services exist and what state they are in. The command-line view is quicker than clicking through panels and it prints the type next to each entry.

scutil --nc list
scutil --nc show "Office VPN"

The first command lists configured VPN services with their current status, and the second prints the selected service's settings, including the type and the server address it will contact. Compare that address with the gateway you were told to expect, because a stale entry pointing at a retired host is a common inheritance problem.

These commands display configuration and status; they do not prove that a tunnel is carrying traffic. If the service is disconnected, the output describes intent rather than a working session. A connected service with no traffic is a different problem again, usually routing or DNS rather than the protocol type. Keep those three observations separate or the diagnosis collapses back into guesswork.

Keep stored settings apart from a live session

A saved profile is a statement of intent. It does not show that the gateway still offers that service, that this profile is the active one, or that a session negotiated successfully. Those are three separate questions and each has its own evidence.

Use the owner's status view or diagnostic tooling to identify the active connection and the identity the gateway presented. A port scan or a certificate seen on an unrelated site answers neither question, and a certificate common name is not the same thing as the expected remote identifier.

When the stored type no longer matches what the gateway supports, get a replacement profile from its owner. Changing the type string does not translate credentials between protocols, and it does not make one authentication arrangement into another. Share the summary through the approved support channel as well, since exported configurations can carry credentials and private keys that a support request never needed.