OpenConnect TOTP prompt missing in NetworkManager: four checks

The gateway accepts the password, asks for a code, and the dialog offers no field for it. Nothing was mistyped: the NetworkManager plugin completed the secret exchange without requesting the six-digit value. Work through the four checks below in order, because only one of them changes the client. The rest of the list rules out the gateway, the account and the plugin build.

Check one: read where authentication stopped

A wrong password fails immediately. A missing second factor fails after the credential step, usually with a repeated prompt or a timeout on the gateway side. The timing and the gateway log tell you which round was left unanswered.

Read the connection log before touching the profile. If the gateway reports an incomplete authentication or a timed-out challenge, the client never sent the code. If it reports invalid credentials, the password is the problem and no TOTP setting will fix it.

Note the exact prompt sequence the gateway expects: username, password, then code, or username, code, then password. Some gateways reorder the rounds, and a client that only knows the first order will stall at the second.

Check two: use the client that owns the challenge

OpenConnect itself implements the full conversation, including the challenge round. Running it directly is the most predictable way to confirm that the account and gateway work:

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

The client prompts in the order the gateway asks. The user agent matters because some gateways tailor the login flow to a known client, and a generic string can produce a shorter flow that never asks for the code. Run it in the foreground once before arranging any background service.

If the command line prompts correctly, the account, the gateway and the second factor are fine. The remaining problem is the plugin's dialog, not the authentication service. That isolates the failing component without touching the server. Keep the command output with the incident record.

If the command line also skips the prompt, stop and check the gateway configuration with its owner. No desktop client can answer a challenge that the server never sends.

Check three: see whether your plugin exposes TOTP mode

Some NetworkManager OpenConnect builds expose a token mode and a user agent field in the connection's Identity tab. Set the user agent to the value the gateway expects, select manual TOTP entry, and save the connection.

Whether those fields exist depends on the plugin version and on which connection editor the desktop uses. A standalone editor may show options that the GNOME panel hides, or the reverse. Check the installed package version before hunting for a hidden setting.

If the token mode is present and the prompt still does not appear, the build lacks the challenge handoff between the plugin and the generic secret dialog. Retyping the password, reinstalling the same package or clearing the keyring will not create a field that the build does not implement.

Check four: treat a generated code as a tradeoff

A script can call oathtool for the current code and pipe username, password and code into nmcli connection up --ask. The sequence works, but the shared secret ends up stored somewhere readable by whoever can open the script, and that reader can mint codes forever. That is a permanent extension of the credential surface, not a client fix.

Anyone who chooses it should lock the secret file to root, keep generated values out of shell history and treat the script as credential material. A wrapper that echoes the code to the terminal throws the second factor away. Test the wrapper with a throwaway account first.

The script also has to follow the gateway's prompt order. If the server asks for the code before the password, a fixed input sequence sends the wrong value to the wrong prompt and produces the same incomplete authentication. Rehearse it against a test account before wiring it into a login job.

Confirm the same gateway and account

Test every workaround against the same gateway, the same account and the same tunnel group. A gateway that also requires a device certificate can reject the command-line client for a reason unrelated to TOTP, and the prompt order may differ from the one you rehearsed.

Record the client, its version, the user agent and the prompt sequence that worked. That record tells the next person whether the issue is the plugin build, the gateway flow or the account policy, without another round of password resets.

Finish by reconnecting once after a full logout. A cached secret can make a broken flow look fixed until the next session, and the second connect is where the missing prompt usually returns.