An idle VPN timer counts traffic, not keyboard activity

The timer that disconnects an idle VPN session is counting packets, not keystrokes. It observes the absence of communication on the tunnel, so a laptop with mail, a backup agent or a chat client in the background never looks idle to it. That one fact explains both directions of the usual complaint: a session that survives a long lunch, and a session that dies in the middle of active work. Decide which clock you are fighting before you go looking for a setting.

What the timer actually observes

On a Cisco ASA the knob is vpn-idle-timeout, set under a group policy or a user policy, and it measures a period without communication activity. The unit is minutes, the default is inherited, and the check runs against traffic counters on the session rather than against anything the operating system knows about input devices. The gateway has no idea whether a human is at the keyboard. It knows when it last saw a packet from that client.

The second clock is vpn-session-timeout, and it is absolute. It starts when the session is established and expires regardless of how busy the tunnel is. A session that ends after exactly one hour of heavy use is that timer, not an idle timer, and no amount of typing will extend it.

Read both values before you change either, because they fail in ways that look identical from the user's chair.

Three different clocks people call idle

Three unrelated policies get described as the idle timer, and only one of them is about network silence.

The third row is the one people actually want when they say the VPN should lock when someone walks away. A VPN timer cannot measure presence. If the requirement is that an unattended laptop loses access, that belongs in screen-lock and device policy, where it can be enforced regardless of background traffic.

Mixing the three produces requests like disconnect after thirty minutes of no typing, which no VPN gateway can implement honestly.

Find the policy that owns this connection

Identify the client and the protocol before you look for a setting. The built-in macOS Cisco IPsec profile, a native L2TP connection and Cisco Secure Client do not expose the same controls, and a screenshot of a disconnect-if-idle checkbox in one of them is not evidence about the others. The native profiles expose little beyond the server, the account and the shared secret. The timer lives on the gateway.

On the ASA, read the effective policy for the user or group rather than the default policy for everyone:

show running-config group-policy NAME | include timeout
show vpn-sessiondb detail anyconnect filter name USER

The session detail output lists the idle and session timeouts that were actually applied, with the time remaining. That is the effective policy, inheritance included, which a running-config excerpt cannot tell you. Compare it against the group you believe the user is in, because a user policy overrides the group policy.

Why your Mac looks connected after thirty minutes

Background traffic is the usual answer, and it is not a bug. Mail, photo sync, an update check, a chat client holding a socket open, or a browser tab with a websocket each produce packets the gateway counts as activity. The tunnel stays up because it is genuinely being used, just not by you. Watch the counters rather than the screen if you want proof.

The mirror image is the session that drops while you are typing, which is a session timeout or an administrator's policy change, not idleness.

There is a client-side effect worth knowing too. Some clients send their own keepalives or dead-peer probes, and those packets reset the gateway's idle counter. That is why a keepalive added to defeat a timeout works, and why it is the wrong tool: it changes the evidence the timer sees without changing the authorization requirement behind the policy.

Change the right knob without breaking the point of it

If the goal is to end a class of connection after approved network inactivity, ask for exactly that in the policy language, and keep the maximum session duration as a separate and deliberate value. Then test it under the administrator's procedure with background work accounted for.

If the goal is to stop access when a person leaves the desk, the VPN is the wrong layer to enforce it.

Never add a traffic-generating keepalive just to keep a session alive past a policy written to end it. That converts a control into a formality, and it gets found in an audit rather than in a ticket. Change the policy, or change the requirement.