AnyConnect Drops When a Terminal Closes: Session Checks

The tunnel is up, you close a spare terminal, and the VPN goes down without a single keypress in the client. On the Linux AnyConnect client the reported cause is session accounting rather than routing: the client records which login sessions existed when the tunnel came up and treats the end of any of them as a reason to tear it down. The checks below run in order, and the first one that fails tells you whether you are looking at this behaviour at all. Nothing in the client's usual output mentions a terminal, which is why the first instinct, blaming the concentrator, is usually wasted effort.

Do not start by editing system files. Each step either explains the drop or removes a candidate, and the cheap steps come first.

Separate a session drop from an underlay drop

Reconnect immediately after the disconnect. A tunnel that comes back within seconds, on the same network, with no new credentials, points at a local trigger such as a closed session rather than a dead uplink, Wi-Fi roam or an idle timeout on the concentrator. A tunnel that hangs on Connecting, or that fails until you change networks, is a different article.

Write down what was open when the tunnel came up: the terminal you ran the client from, any second shell, the graphical login, and any SSH session from another machine. You need that list in a moment, and reconstructing it from memory after the next drop is unreliable.

Check what the client recorded at connect time

The client is not inspecting process parents or terminal ownership. It snapshots the set of login sessions present at connect time and compares that set later; when a member disappears, the comparison fails and the tunnel goes with it. That is why closing the window you connected from can be harmless while closing an unrelated spare terminal kills the connection: what matters is whether that session was in the original set. The check is a set comparison rather than a count, which is why replacing a session can be as fatal as losing one.

List what the client could see before you change anything:

who
w
last -n 10
sudo ls -l /run/utmp

Every line from who is a user process entry in utmp. If your session appears twice, once for the graphical login and once for the terminal, both entries existed at connect time and both are candidates.

Remove only your own entry from utmp

The published workaround makes the session you are about to use invisible in utmp before the client starts. A small C program walks getutent(), matches the record whose ut_line equals the TTY of standard input, then rewrites that record. The order is deliberate: setutent(), read the entry, copy its ut_id, set ut_type to DEAD_PROCESS, clear the user and line fields, write it back with pututline(), then endutent().

Compile it, then run it as root from the shell that will start the client:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

Two failure modes account for most reports that the tool does nothing. It acts on the TTY attached to standard input, so running it from a script or a cron job with no terminal leaves it nothing to match. And /run/utmp is not writable by ordinary users, so a non-root run fails silently unless you check the exit status.

Verify the tunnel survives the close

Test the mechanism instead of assuming it. Connect from a session you intend to keep, open a second terminal, close the second one, then confirm the tunnel is still up with vpn state and a look at the interface list. If the tunnel survives, the trigger was a specific session type rather than every session, and you have found the session that has to stay open.

If it still drops, the watched session was somewhere else — most often the graphical login that spawned your terminal — and stripping one TTY entry will not help. Repeat the observation with the full list from the first step rather than adding more surgery.

When the utmp rewrite is the wrong answer

utmp is shared accounting, not a private table. Rewriting the entry of a session that is still alive makes who, w and some audit tooling under-report it, and a program that later closes the same entry can fail outright. Keep the tool limited to your own session, keep a copy of the original file, and do not turn it into a boot service that strips every record.

If your site collects session accounting for compliance, the workaround conflicts with that requirement and the supported answer is a client version or a different access method, not a patched utmp. For most people the least invasive fix is simply to start the client from a session that will stay open all day and to leave that window alone.

Before you close the ticket, record which session the client was watching when the tunnel came up. That single line is what turns a mysterious disconnect into a reproducible condition for the next person on the machine.