Two shortcuts remove the guesswork a single VPN toggle has to handle: one always connects, the other always disconnects. Two shortcuts remove the ambiguity: one always asks for a connection, the other always asks for a disconnect. Both point at the same saved profile through its UUID.

Walk the setup in the order below. Test each command in a terminal before binding it, because a shortcut is a poor place to discover a prompt you cannot see.

Find the UUID, not the profile name

List the saved connections in your normal desktop session and copy the UUID of the intended VPN. The name is for people; two saved profiles can share one, and a profile that is deleted and re-imported gets a new identifier.

nmcli connection show
nmcli connection show "Office VPN" | grep -i uuid

Keep the UUID in the shortcut definition rather than the display name. If the profile is replaced later, update both shortcuts at once, because one stale identifier produces a Connect action that fails while Disconnect still targets the old object. That is why both actions use the same value. Treat the UUID as the profile's identity.

Confirm that the profile is a NetworkManager VPN and not a vendor daemon with its own service. A vendor client needs its own supported control interface; nmcli will not manage a tunnel it does not own. Check the connection type if the name is ambiguous. A tunnel owned by another daemon will not appear in the same list.

Test both commands in a terminal first

Request the connection interactively, complete the approved login and reach a private resource you actually need. Then disconnect with the matching command and confirm that the VPN goes down without taking the underlying Wi-Fi or Ethernet link with it.

nmcli --ask connection up uuid 11111111-2222-4333-8444-555555555555
nmcli connection down uuid 11111111-2222-4333-8444-555555555555

Run them as two separate actions. They change connection state; they do not delete the profile or edit its settings. Keep the terminal output for the first run so you know what a normal prompt sequence looks like. That record makes the shortcut behavior predictable.

Do not test the disconnect through your only remote administration path. If the VPN carries your session, a successful disconnect also ends your access, and recovery needs a path that does not depend on the tunnel. Keep a local console or a second link available.

Bind two named shortcuts to the same UUID

In the desktop's keyboard settings, create two clearly named actions, for example Connect Office VPN and Disconnect Office VPN. Assign different key combinations and paste the reviewed UUID into both commands.

Name them by intent rather than by state. A shortcut called Toggle makes the next press unpredictable; Connect and Disconnect each describe exactly what will be requested. That makes the shortcut list self-documenting. A misplaced press still does something predictable.

If the desktop uses desktop-entry launchers, remember that a launcher does not automatically allocate a terminal. A command that needs interactive input will sit waiting where nobody can answer it.

Put the authentication prompt where you can see it

Without --ask, nmcli asks a running secret agent for missing credentials. That is the right path when the desktop already handles this VPN's authentication and the agent can display its own prompt. Test the plain Connect command from the shortcut itself before assuming it works.

If the VPN needs terminal interaction, configure the shortcut to open the desktop's terminal application and run the interactive command there. Launch arguments differ between terminal applications, so use the installed one's documented form.

For a desktop entry, Terminal=true requests a terminal window and Terminal=false does not. Neither setting is a reason to put a password in the command line, grant passwordless sudo or bypass the organization's authentication policy.

Check readiness after the key press

A key press means you requested activation. It does not prove that authentication finished, routes were installed or private DNS is answering. Check the connection status and then the actual private resource.

Read the status through the owning client rather than by matching a translated sentence. Human-readable text changes with language, and a machine can have more than one VPN, so a string match can report the wrong profile or miss a transitional state.

If another automation reconnects the VPN, reconcile it with the Disconnect shortcut. Two owners that reverse each other produce a connection that appears to ignore the key press, when the real problem is competing policy.

Record the UUID, both commands and the readiness check in your notes. The next profile replacement or desktop upgrade is much easier to diagnose when the identifier and the intended prompt path are already written down.

Winndannde jowitiiɗe heen