vpncli -s vs the GUI: Log In to Cisco Secure Client

Cisco Secure Client gives you two ways to answer the same login prompts: a person typing into vpnui.exe, or a script feeding answers to vpncli.exe through standard input with -s. The second one makes scheduled connections possible without screen-scraping the GUI, and it also converts a login into a file that has to be protected like a credential. Which one you want depends on whether the machine has a human at it, and how often the password rotates. Neither option changes what the gateway asks for, only who is answering.

Both paths end in the same tunnel, so the comparison is about operations, not protocol.

Two ways to answer the same prompts

The GUI path is interactive by design: the client asks, someone answers, and the session lives as long as that person leaves it alone. It is the right choice on a laptop that a human uses, because the prompts adapt to the gateway's authentication method and nobody has to keep a plaintext password on disk.

The script path is right for a kiosk, a lab box or a scheduled task where no one is present to type. The trade is explicit: you accept a credential file on disk in exchange for unattended connection. If the gateway offers certificate or SAML authentication, that trade is usually not worth making, because the file exists only to answer prompts a stronger method would avoid.

Do not mix the two on one machine at the same time. The command line and the graphical client compete for the same session state, which is the next section's problem.

What the answer file must contain

The client prompts in order — gateway, sometimes a group selection, username, password, and any banner acknowledgement. A file that answers all of them looks like this, with real values substituted:

connect vpn.example.com
MyGroup
alice
correct-horse-battery
y

The reliable way to build that file is to connect once by hand, write down every line you type and every Enter you press, and then reproduce exactly that sequence. Deployments that store the group and username in the profile may need blank lines where those prompts no longer appear, and the last line still needs its own newline. A file that is one line short usually hangs at the final prompt instead of failing with a clear error, which is why it gets blamed on the network. Diff the file against your transcript twice, once for order and once for the blank lines.

Keep the file outside any synced folder and readable only by the account that runs the task. That password is plain text, so the file is a credential: no repository, no shared drive, no attachment in a ticket. The client will not warn you about any of this.

Why the GUI has to go first

Start the script by ending the GUI process, then run the CLI from its own installation directory, because both the working directory and the client build matter. An illustrative wrapper:

@echo off
taskkill /IM vpnui.exe /F >nul 2>&1
cd /d "%PROGRAMFILES(x86)%\Cisco\Cisco Secure Client"
vpncli.exe -s < C:\secure\login.txt

Exit codes are not a dependable success signal here. The client prints its progress and keeps the tunnel in a separate process, so read the output for the connection state and only then start the work that depends on the VPN.

If you skip the GUI kill, the script can appear to run while the existing session stays in whatever state the user left it. That failure looks intermittent, which is exactly the kind of bug that survives a week of guessing.

Confirm a session, do not assume one

After the script returns, check something that exists only inside the tunnel — an internal host, or a DNS suffix that only the corporate resolver answers. Parse the client output for its connected state line as well, and treat anything else as a failure rather than a slow success. Re-running the file while a session is already up can leave the client half-configured, so either disconnect first or skip the login when the session is present.

Then decide who owns reconnection. A loop that pings an internal address and re-runs the login can keep a kiosk online for months, and it can also lock an account the first time the password rotates. Bound the attempt count, alert when it trips, and let the identity team rotate the file instead of leaving a stale password retrying into a lockout.

Older vpnclient.exe is not the same tool

The same automation appears under an older name, and the two are not interchangeable. The retired Cisco IPsec client used vpnclient.exe with inline arguments such as a connect verb, a profile name, a user and a password on one command line; vpncli.exe expects a prompt sequence on standard input with -s. Copying an old forum script onto a current machine therefore produces a command that runs, does nothing visible, and gets blamed on the gateway.

Before editing any arguments, check which client is installed and which one the script actually calls. The name difference is small enough to miss in a scheduled task, and it is the first thing to verify when an inherited script has stopped working after an upgrade.