P2S VPN (OpenVPN + Entra ID auth) TLS handshake times out after ClientHello — server-side packet capture shows zero packets reach the tenant gateway worker

Summary

Point-to-Site VPN connections to a newly provisioned Azure VPN Gateway (OpenVPN protocol, Microsoft Entra ID authentication) consistently fail during the TLS/control-channel handshake, ~14-23 seconds after the client sends its ClientHello. Microsoft Entra ID authentication completes successfully every time — the failure occurs strictly after auth, inside the OpenVPN tunnel negotiation. Reproduced on 13+ attempts across 2 days, 2 independent client machines (macOS and Windows), 2 different Entra user accounts, multiple networks (including a mobile hotspot), and 2 independent gateway instances (including a full delete + recreate with a new public IP). The failure is 100% consistent regardless of client OS, user, network, or gateway instance.

A native VPN Gateway packet capture on the backend (see below) now shows the failure is very likely happening in Microsoft's own shared front-end/routing layer, not in anything client- or tenant-configuration-side.

Second reproduction: independent Windows client, independent user

A colleague (different Entra account) on a separate Windows machine, using the official Azure VPN Client for Windows (app version 4:0:5:0), reproduced the identical failure against the same (recreated) gateway:

{
  "ProfileName": "<vpn-profile-name>",
  "FailureReason": "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.",
  "FailureErrorCode": -2147014836,
  "FailureCategory": "ControlPath",
  "GatewayVip": "<gateway-public-ip>"
}

Microsoft Entra ID authentication is explicitly logged as succeeding ("AAD Authentication succeeded", "Success Received Microsoft Entra Credential Token") on every attempt. FailureCategory: "ControlPath" confirms the failure occurs at the same OpenVPN control/TLS channel stage seen on macOS — not during authentication.

Environment

• Subscription: <subscription-id> (can provide privately)
• Entra tenant: <entra-tenant-id> (can provide privately)
• Region: uksouth
• Gateway:
  • Resource GUID: <gateway-resource-guid> (can provide privately)
  • SKU: VpnGw1AZ, Generation1, RouteBased, zone-redundant
  • Public IP: <gateway-public-ip> (can provide privately)
  • Gateway hostname seen by client: <gateway-hostname>.vpn.azure.com
• P2S config: Tunnel type OpenVPN (+ IKEv2 also enabled, unused since Entra ID auth only supports OpenVPN), Authentication type Microsoft Entra ID
  • Tenant: https://login.microsoftonline.com/<entra-tenant-id>
  • Issuer: https://sts.windows.net/<entra-tenant-id>/
  • Audience: <custom-app-audience-id> (custom app registration)
  • Client address pool: 172.20.0.0/24
• Client: Azure VPN Client for macOS, app/tunnel version 3.0.100 (4.0.100), macOS 26.5.2, arm64

Symptom

Every connection attempt follows this exact sequence:

1. Client acquires an Entra ID access token for the custom app's scope — succeeds every time.
2. TCP connects to the gateway on port 443 — succeeds (~100-300ms).
3. OpenVPN control-channel handshake (P_CONTROL_HARD_RESET_CLIENT_V2 → server ack → reset received) — succeeds (~100-300ms round trip).
4. Client sends the TLS ClientHello to begin the OpenVPN TLS session.
5. ~13-15 seconds later, the connection is torn down:
   • "Remote peer closed connection" / "Error in OS wait for ready: Operation timed out" (macOS, MobileAccess error code 34), or
   • "Timed out waiting for state to change" (macOS, MobileAccess error code 41), or
   • FailureErrorCode: -2147014836, FailureCategory: "ControlPath" (Windows)

No server-side TLS alert or explicit rejection is ever received — the client simply times out waiting for the server's continuation of the TLS handshake after ClientHello.

What has been ruled out

Key finding: server-side packet capture is consistently empty

Using the native VPN Gateway packet-capture feature (https://learn.microsoft.com/azure/vpn-gateway/packet-capture), captured on both backend gateway instances (GatewayTenantWorker_IN_0 and GatewayTenantWorker_IN_1 — zone-redundant VpnGw1AZ) across three separate windows, including a final 10+ minute window with multiple deliberate connection attempts during capture. All three captures came back completely empty on both instances every time — each resulting .pcap file is exactly 24 bytes (a valid pcap global header, zero packet records). Verified with tcpdump -r and a hex dump — genuinely empty, not truncated/corrupted.

This is significant: client-side logs clearly show a real, bidirectional exchange (TCP connects, HardResetClientV2 is sent and acknowledged by something server-side) before the eventual timeout — yet the packet capture scoped to the tenant-specific worker instances shows this exchange never happened.

Likely explanation: the gateway's public-facing OpenVPN/TLS listener is served by a shared front-end/routing tier that terminates the initial TCP + control-channel handshake itself, and is expected to hand the session off to the tenant-specific GatewayTenantWorker backend for the actual TLS negotiation. That hand-off appears to be failing or never completing. If correct, this isn't visible or fixable from the customer side — it needs investigation on Microsoft's shared front-end/routing layer for this gateway's OpenVPN endpoint.

Ask

Please investigate the backend OpenVPN/TLS listener for this gateway (resource GUID available privately) for why the TLS handshake never completes after ClientHello, despite successful Entra ID auth and a successful control-channel handshake.

Windows client connection IDs for backend correlation:

• {c228237f-c373-46e1-8118-47ad32d0a4b2} — 2026-09-06 12:47:34-12:48:24 UTC
• {7b1bf9c4-5308-441a-a7cb-c175585178c0} — 2026-09-06 12:49:43-12:50:03 UTC

Happy to provide full client-side log files, packet capture files, and exact subscription/tenant/resource identifiers privately on request.