Mac Keeps Asking for a VPN Password: Keychain or Account?
The Mac may want a login keychain password, an admin password or the VPN account itself. Read the dialog owner, then fix the right store.
You unlock the Mac, open the VPN client, and a password sheet appears before the tunnel has even started. You type the gateway password, and either it is rejected or the sheet comes back a moment later. Then it asks again after a wake from sleep, a logout, or a client update. That sheet is rarely the VPN server asking for credentials; usually macOS is asking permission to read, unlock or change a local record, and the password belongs to that record's owner, not to your VPN account.
Match the sheet to the identity behind it
Four prompts look almost identical, and only one concerns the gateway. The wording, the process requesting access, and the item named underneath tell you which one you face.
| What the sheet says | Whose password it wants | What it does not do |
|---|---|---|
| Enter the password for the login keychain | The local keychain password, normally your Mac login password | It does not authenticate you to the VPN server |
| An app wants to use confidential information stored in your keychain | Approval for that app to retrieve one item | It does not grant privileges at the gateway |
| macOS wants to make changes, and asks for administrator authorization | An admin account on this Mac, for the named setting | It does not change the VPN account password |
| The client itself asks for a username and password to connect | The remote account, certificate or profile credential | It does not unlock anything local |
A dialog about local access proves nothing about the server. A gateway rejection appears inside the client with the vendor's error text, not as a system sheet offering to unlock a keychain. The reverse is as common: typing the gateway password into a keychain sheet leaves the record locked and adds a failed attempt.
The dialog names an owner, a store and an action
Keychain prompts are about retrieval, not authentication to anything remote. Apple's description of the request dialog is narrow: Allow Once, Always Allow and Deny control whether that app may read the stored item. None of the three grants a privilege at the gateway or changes what the server thinks of your password.
When the requester is a client that just updated, re-approval is expected: the new build no longer matches the access control list on the item, so macOS asks again. Answer Allow Once while diagnosing. Always Allow is a standing grant to that app and the wrong answer for a helper process you did not expect; deny and check the vendor if the binary is not the client you installed.
A prompt asking for administrator authorization is a third animal. It names a system setting or protected store being changed, and the credential it wants is an admin account on this Mac. Not every personal keychain item needs that; the ones behind network configuration usually do, because the configuration belongs to the system, not your login session.
Where a Mac VPN password can live
Keychain is one possible store, not the definition of one. A built-in VPN configuration created in System Settings keeps its credentials with the network configuration, as a managed system setting. A third-party client usually keeps an item in your login keychain: a generic password keyed by a service name, or an internet password keyed by server, protocol and account. Many newer apps use the data-protection keychain instead, whose items never appear in Keychain Access.
People search Keychain Access for the VPN name, find nothing, and conclude the password is not stored. Apple's TN3137 note says more than one keychain implementation exists; absence from that list is normal, not proof of a broken item.
The record types are not interchangeable either. An account password, a private-key passphrase, a client certificate and an IPsec shared secret fail differently and are repaired in different places; retyping a saved password does nothing for a rejected certificate. If the Mac is enrolled in management, the profile is another owner: a VPN payload can carry credentials and reapply them on refresh, so deleting a local item is temporary until an administrator changes it.
When the login password and the keychain password drift apart
The login keychain normally uses your Mac login password, which is why the two can drift. An administrator resetting your password from another account, a recovery flow, or a directory change can leave the keychain locked to the old value, and macOS then asks for a password you did not just set.
At login you may see a warning that the system could not unlock the keychain. Updating it needs the old password, which is fine if you remember it and useless if you do not. The two honest repairs are Keychain Access, Edit, Change Password for Keychain "login", or a fresh login keychain with the credentials you need re-entered. The second option destroys stored items.
Do not reset the whole keychain because one VPN rejects an old credential: that takes out unrelated accounts and still does not identify the item.
One command settles the local-versus-remote question. Ask the keychain for the item directly:
security find-internet-password -s vpn.example.com -a [email protected] -g
security find-generic-password -s "Client Name" -a [email protected] -gUse the server and account from your client's settings. If the same approval sheet appears when you ask the keychain yourself, the prompt is local and the server is a bystander. If no such item exists, the client is not storing the password where you assumed. The -g flag prints the secret to the terminal, so avoid screen sharing.
Update the record the client actually reads
If the account changed at the gateway, change it there first, then update the stored record through the client's settings. Editing a keychain item by hand is unreliable: the client may read a different service-and-account pair, and a managed profile will overwrite your edit.
For a suspected stale item, match service, account and protocol before deleting anything:
security delete-generic-password -s "Client Name" -a [email protected]Deleting a similarly named item from another connection is a common self-inflicted outage. Removal is only local: it does not revoke a session on the gateway, unbind a device certificate, or change the account's password.
Confirm the fix survives a reboot
Connect, wake from sleep, log out and back in, then reboot once. A clean sequence with no sheet and a client status naming the expected account is the only evidence that counts. Where the prompt returns tells you which layer you missed: after an update it is approval, after a network change the client's own prompt, after a reboot a profile reapplying state.
Check the client for a remember-password or always-ask setting before you touch the keychain again. Some configurations, particularly IKEv2 with per-user authentication, prompt by design on every connect; keychain repair will not help.
Write down the item you changed, the store that owned it, and the account it belonged to, so the next prompt takes seconds to place. Apple's Keychain access requests page is the reference for what those three buttons authorize.