Why an Azure OpenVPN tunnel drops about every sixty seconds

The tunnel finishes its handshake, carries traffic for about a minute, then reconnects. That sequence rules out the usual suspect, because a firewall blocking the port would have stopped the handshake rather than the session. What you have is a liveness disagreement: one side decided the other had gone quiet and tore down a working tunnel. The log line says which side, and it chooses the fix.

Read that line before touching any timer.

The myth: something in the path is blocking the tunnel

If a port were blocked, the connection would fail at the start and stay failed. A repeating cycle means control messages are flowing, sessions are establishing, and something later in the conversation keeps expiring. Blocking produces silence, and this produces a rhythm.

Rhythm is the useful clue. Timers produce it; packet loss rarely does.

Read the disconnect reason before the timer

OpenVPN names its reason, and each name points at a different subsystem. Session invalidated: KEEPALIVE_TIMEOUT is a timer expiring, so compare ping and ping-restart values on both ends. AUTH_FAILED is credentials or certificate state, and no timer change will help. A TLS error means the peers never reached the keepalive stage at all.

Record the connect time, the disconnect time, and whether the interval is stable to the second. That single measurement separates a configured schedule from a coincidence.

A stable interval is a timer. A drifting one is more likely a path problem or a displaced session.

Two keepalive timers that never agreed

Profiles exported from the portal sometimes still carry keepalive or ping-restart lines copied from a community-server template. The gateway runs its own dead-peer detection and pushes its own expectations, and the two schedules do not have to match. When they disagree, the client restarts on a schedule the gateway never agreed to.

The two values are not the same control. ping is how often the client sends an echo, and ping-restart is how long it waits without hearing anything before it tears the tunnel down. A profile that sets a short ping-restart and a gateway that answers slowly will restart on every quiet period, which is exactly the shape of a one-minute cycle.

The minimal client-side change is to neutralise the timers at the top level of the profile, outside every inline block:

keepalive 0 0

Save, reload the profile, reconnect. A session already in memory keeps the old values, which is why the edit sometimes looks like it did nothing.

The certificate name can move under you

Azure certificate authentication depends on the client trusting the name the gateway presents today. A verify-x509-name line in an older download can pin a name that a gateway rebuild or a certificate renewal has since changed, and the mismatch surfaces as a reconnect loop rather than a clear error. Deleting the line restores connectivity, which makes it a decent diagnostic and a poor permanent fix, because it also removes verification. Once the tunnel holds, restore the line with the name the gateway actually presents.

Test a second client generation on the same machine before editing the gateway. If one client loops and the other holds, the profile is not the problem.

What to change, and in what order

Check for a displaced session next. Two devices sharing one certificate can push each other off, and the result looks periodic because both sides keep reconnecting. Compare the point-to-site session records for the same identity appearing again and again.

Then test the idle path by running continuous traffic for several minutes. If the drops stop while traffic flows, the timer that matters belongs to a NAT device or load balancer on the path rather than to OpenVPN.

Only after those four tests should gateway settings change.