Troubleshooting

Start with vpn-up doctor — it reports your OS, dependency and OpenConnect versions, the active secret backend, and SSO availability.

Usually a stale stored password. Reset it and reconnect:

vpn-up delete-secret "Work VPN" password
vpn-up start "Work VPN"

For Duo, make sure the profile’s method matches what your account expects (push/phone/sms/passcode). See SSO & Duo 2FA.

“Unexpected 404 result from server”

Some Cisco AnyConnect gateways emit this banner on connect. It is benign if the connection then proceeds and the tunnel comes up.

It keeps asking for my sudo password

openconnect needs root, so VPN Up runs it under sudo. That prompt is the safer default — it avoids the ambient passwordless-root problem below, and the sudo password is never stored anywhere. It is a compatibility mode rather than a hardened boundary, though: a user-writable openconnect is a poor sudo target even with a prompt, since a process running as you could replace the binary and wait for your next legitimate sudo openconnect.

⚠️ A passwordless rule is not “just scoped to one binary.” sudoers matches the command, not its arguments, and several openconnect flags (--script, --script-tun, --csd-wrapper, --config) execute a program as root. A NOPASSWD rule for openconnect is therefore effectively passwordless root for your account. On macOS it is weaker still: Homebrew’s prefix is owned by the installing user, so a rule pointing into it can be bypassed by replacing the binary. Read Known limitations before installing one.

Prefer the privileged helper. vpn-up install-helper installs a root-owned vpn-up-helper that builds the openconnect command line itself, so sudoers names only that helper instead of openconnect. It needs a C toolchain, works today with a distro-packaged openconnect on Linux, and currently refuses on macOS (the dyld/Mach-O closure check is not written yet) and on any Homebrew install. It also removes the legacy rule below whenever it runs. Add --passwordless for unattended reconnects, after reading what installation assumes.

If you keep the legacy rule instead (it is what the login service needs until the helper is available on your platform):

command -v openconnect     # verify the real path first

# macOS (Homebrew, Apple Silicon — usually /opt/homebrew/bin/openconnect):
echo "$USER ALL=(root) NOPASSWD: /opt/homebrew/bin/openconnect" | sudo tee /etc/sudoers.d/vpn-up
# Linux:
echo "$USER ALL=(root) NOPASSWD: /usr/sbin/openconnect" | sudo tee /etc/sudoers.d/vpn-up
sudo chmod 440 /etc/sudoers.d/vpn-up

SSO browser doesn’t open (Linux)

Because openconnect runs as root, a root-spawned browser may not reach your desktop session. Point VPN Up at a session-aware opener via VPN_UP_EXTERNAL_BROWSER — see the SSO guide.

“SSO needs openconnect >= 9.0”

Browser-based SSO uses OpenConnect’s --external-browser, added in 9.0. Upgrade:

brew upgrade openconnect          # macOS / Linuxbrew
sudo apt install --only-upgrade openconnect   # Debian/Ubuntu

Check with openconnect --version or vpn-up doctor.

Correct — SSO needs an interactive browser, so service install refuses SSO (and Duo passcode) profiles. Use a non-interactive method (push/phone/sms) for the login service.

Still stuck?

Open an issue on GitHub with the output of vpn-up doctor and the last lines of vpn-up logs (redact anything sensitive).