Stop the Right OpenVPN Connection: Foreground, systemd or NM

Closing a terminal window is not the same as closing a tunnel, and killing a process is not the same as stopping a service. On Linux the command that actually disconnects depends on which component started the connection and therefore owns its lifecycle. The comparison below covers the four arrangements you are most likely to meet, and the identifier each one needs.

Foreground and daemonized clients

A client started by hand in a terminal belongs to that terminal. Ctrl+C delivers an interrupt, the client tears down its interface, and the tunnel ends. Nothing else has to be told.

A client started through a shell wrapper and left in the background belongs to nobody in particular, and that is the case where people reach for killall. Find the process first, confirm its command line mentions the profile you mean, and then send the normal termination signal. A supervised process killed underneath its supervisor will simply be restarted, which is why identifying the owner matters more than choosing a signal. Signal the process group only when you have confirmed that no other tunnel shares it.

SIGUSR1 is not a disconnect; it asks the client to restart the tunnel.

systemd instances

When a unit owns the connection, the unit is the object to stop. Template instances such as openvpn-client@office carry the profile name, and stopping the template target instead of the instance can affect every client on the host.

systemctl list-units 'openvpn-client@*'
systemctl stop [email protected]

Read the unit's ExecStart when you are unsure which profile the instance loaded.

A unit that is enabled will come back at the next boot, which is a separate decision from stopping it now. Disable it only after deciding the connection should not return, and record that decision where the next administrator will find it.

NetworkManager profiles

A profile managed by NetworkManager is not a process you can signal. The manager owns the lifecycle, and the object to act on is the active connection, identified by UUID rather than by display name. Reading the active list first also shows whether a second tunnel is running under a name you did not expect.

nmcli connection show --active
nmcli connection down uuid actual-uuid

Display names repeat, and a profile file's name is not its identifier, so copy the UUID from the listing. If the connection comes straight back, something is activating it: a secondaries entry on a base connection, a dispatcher script, or an autoconnect flag. Stopping the manager's connection is the right first step, and the reactivation is the next question. Do not delete the profile to stop the reactivation, because that also removes the credentials you may need tomorrow.

The manager's command reference documents how a down target is selected.

OpenVPN 3 sessions

OpenVPN 3 Linux uses a session model rather than a process per tunnel. You inspect the sessions the service knows about, then act on one session path. The path is the identifier, and it is not interchangeable with a configuration name.

openvpn3 sessions-list
openvpn3 session-manage --path /net/openvpn/v3/sessions/... --disconnect

Disconnecting every session is a different action, and it should be a deliberate one.

The same host can hold sessions from several users, so list before acting and confirm the owner of the session you are about to end.

What to verify afterwards

Check three things after any of these stops: the active connection list no longer contains the tunnel, the interface is gone, and a route lookup for an internal address no longer selects a tunnel device. Then decide what happens at the next boot.

ip -brief address
ip route get 10.8.0.1

Removing an interface by hand does not stop the owner, and it leaves the cleanup half done.

Disconnecting now, preventing the next automatic start, and allowing non-VPN traffic afterwards are three separate choices. Make each one explicitly.