Azure VPN Client 3.4 disconnects hourly: sign-in frequency

One user connects, works, then is dropped once an hour with a message that authentication with Microsoft Entra has expired. Reconnecting works and the cycle repeats on a stopwatch. On a point-to-site gateway where nothing was deployed, that pattern points at the credential rather than the tunnel. Azure VPN Client 3.4.0 began enforcing Conditional Access sign-in frequency during an established session, a policy that earlier clients evaluated only at sign-in.

Work through the six checks below in order. Each one either confirms the schedule or rules it out, and stopping early is how a gateway gets rebuilt for nothing.

Step 1: read the exact message

The wording separates the layers. A message about Entra authentication expiring is a token statement; a tunnel or security association error is not. Write down the elapsed time too, measured from connect to disconnect rather than from the start of the working day.

If the user can reconnect immediately and the gateway still shows a healthy tunnel, you are looking at token expiry rather than a dead peer.

Step 2: get the client version

Read the version from the app, not from the deployment record. The change arrived with 3.4.0, so 3.3.1 and earlier keep an established tunnel alive regardless of the policy. One unmanaged laptop on an older build behaves perfectly while the rest of the team drops hourly, which is the kind of split that sends people back to the gateway. Version is a property of the client, and the gateway has no idea which build is connected.

Update one test device first and watch the clock. A device that starts dropping on the policy interval after the update confirms the mechanism without touching production policy.

Step 3: find where the policy lives

Sign-in frequency is a Conditional Access setting on the policy that targets the Azure VPN enterprise application. It is not on the VPN gateway resource, not in the point-to-site configuration, and not in the client profile. Search the policy list for the Azure VPN app and read the session controls.

Two policies can apply to one user, and the stricter one wins, so a value you never set may be the one in force. Check for a tenant-wide baseline policy as well as the app-specific one. Report scope matters too: a policy that excludes a group produces a population with different behaviour and no obvious explanation.

Step 4: do the arithmetic

The disconnect lands one hour after the sign-in frequency value in the behaviour Microsoft documents for this client, so a seven-hour frequency yields roughly eight hours of connectivity. That offset is why a value chosen for an eight-hour day looks broken in the afternoon while a nine-hour test looks fine. Convert the complaint into numbers before changing anything: connect time, disconnect time, difference, then compare with the policy value plus one hour.

If the difference does not match that sum, the schedule hypothesis is wrong and you should stop adjusting policy.

Step 5: separate a schedule from a rekey

IPsec rekey, dead peer detection and idle timeouts produce irregular drops tied to traffic volume or silence, not to a stopwatch. A user dropped mid-transfer and a user dropped after an idle lunch are describing different mechanisms. Ask what the user was doing in the minute before the disconnect.

Certificate problems look different again: the client fails to connect rather than dropping a working session, and the failure is immediate. An MFA prompt that never completes presents as a hang, not as a clean hourly drop followed by a reconnect that succeeds.

Step 6: roll it out without a surprise

Announce the client update before it reaches users through the store, because the behavioural change ships with the client. Pick the frequency from the requirement: a value that covers the working day for usability, or a short value if a lost laptop must lose access quickly. Record which requirement won, since the same setting produces both the protection and the complaint. Then confirm the choice on a device running the new build instead of extrapolating from a pilot that ran the old one.

Keep the message, the version, the policy value and the measured interval in one note. That record answers the next report in a minute rather than a rebuild.