Azure VPN Client With a Work Account: What Breaks and Why

The Windows 10 row causes arguments. The client may still launch there. That is not the same as supported, and a fleet still sitting on Windows 10 has a lifecycle problem showing up as a VPN ticket.

The phone rows are firmer. There is no Microsoft-published Azure VPN Client for iOS or Android. A user who needs internal resources from a phone is an architecture conversation, not a troubleshooting step.

Entra ID authentication requires the OpenVPN tunnel type on the virtual network gateway. If the gateway is not configured that way, Entra authentication is not available to it.

Microsoft states the requirement and gives no rationale. I am not going to invent one. The mechanisms people repeat on forums are provably wrong, and a confident wrong explanation costs more credibility than saying "that is the documented requirement." Verify the setting, move on.

When an administrator downloads the VPN client configuration from the gateway, the package contains a folder named AzureVPN holding azurevpnconfig.xml. If the gateway offers more than one authentication type, the file is split by type: azurevpnconfig_aad.xml for Entra ID, azurevpnconfig_cert.xml for certificate authentication. The certificates themselves live in a sibling folder named Generic.

Now the check worth memorizing. If the AzureVPN folder contains no azurevpnconfig file, the gateway is not configured for Entra ID authentication. Nothing the user does locally will change that. No reinstall, no credential clear, no reboot. Escalate to whoever owns the Azure subscription. This one check saves more technician hours than everything else here combined.

Import is exactly this sequence: open the Azure VPN Client, click +, choose Import, then Open and select the XML. Microsoft documents no double-click-to-import behavior. When a user says they double-clicked the file and nothing happened, nothing is broken.

This is the call that eats an afternoon. The firewall team confirms outbound 443 is permitted. The tunnel still will not come up.

Revocation endpoints are published over plain HTTP by design. A tidy egress policy that allows 443 and blocks everything else looks correct on paper and quietly breaks revocation checking. On guest Wi-Fi and hardened client sites, this is the most common cause behind the "but 443 is open" complaint.

What you should not do is open UDP 1194 or UDP 443. That advice gets copy-pasted endlessly and is not a documented requirement for Azure point-to-site. Punching undocumented outbound holes to chase a symptom is how a workaround becomes a permanent exception nobody remembers approving, which is a cybersecurity problem rather than a VPN fix.

• Run Prerequisites Test (Windows, client version 4.0.0.0 and later) checks the local machine: Windows services, background permissions, local settings permissions, internet access, and device time sync.
• Diagnose, then Run Diagnosis, runs four connectivity tests: Internet Access, Client Credentials, Server Resolvable, and Server Reachable.

Use the prerequisites test when one machine misbehaves and the rest are fine. Use the diagnosis when the client looks healthy but never connects. A Server Resolvable failure is DNS. A Client Credentials failure sends you back to identity.

This detail resolves more confusion than any other. The Entra ID sign-in is out of band: it completes over the user's ordinary internet connection, before any tunnel exists. An unaccepted hotel captive portal, a broken resolver, or a filtering appliance kills sign-in while the VPN configuration itself is perfect. If the browser cannot reach Microsoft, neither can the client.

After a failed sign-in, use Clear Saved Account before retrying. That is the documented remedy, and it clears the stale account state that otherwise makes the second attempt fail exactly like the first.

Someone will say the timezone is wrong and that must be it. It is not. Windows keeps time in UTC and derives local display time from the timezone setting, so a laptop in Round Rock showing Tokyo time still holds the correct UTC.

What breaks authentication is a wrong UTC clock. The real causes are narrow: the w32time service stopped or disabled, NTP blocked outbound at the firewall, a dead CMOS battery on aging hardware, or a dual-boot Linux install writing local time to the hardware clock.

• "WebView2 is causing the blank sign-in window." Widely repeated, no primary source we can find.
• "Your other VPN client is conflicting." Undocumented. Reasonable to try as an experiment, never to state as the cause.
• "You need the KB4577063 FIPS hotfix." That update targeted Windows 10 version 2004, which stopped receiving servicing in December 2021.

The honest limit of this guide: none of it tells you who is allowed to connect, whether a user sees an MFA prompt, how often, or how traffic splits. All of that lives in the customer's own Entra ID and gateway configuration. Any provider promising specific behavior there without reading your tenant is guessing.

• Confirm the platform is supported before anything else.
• Open the profile package and look for an azurevpnconfig file. Missing means escalate, not troubleshoot.
• Confirm outbound TCP 80 as well as 443, from the network the user is actually on.
• Run Prerequisites Test for a single odd machine; Run Diagnosis for a connection that will not complete.
• Clear Saved Account, then retry sign-in once.
• Check UTC time on the device, not the timezone.

The click-by-click companions live in our help center: Connect to Azure VPN with your work account for end users, and Azure VPN prerequisites and troubleshooting for whoever holds the ticket.

Does the Azure VPN Client still work on Windows 10?

Windows 10 is no longer on Microsoft's supported platform list for the Azure VPN Client. Windows 11 is supported, as is macOS 13 or later. An unsupported machine may still connect, but the durable fix is the device refresh, not the VPN ticket.

Why does Entra ID authentication require the OpenVPN tunnel type?

Microsoft documents the requirement and publishes no rationale. We state the requirement and stop, because the explanations circulating in community threads are demonstrably incorrect. In practice it means the gateway must be configured for OpenVPN before Entra ID authentication is available.

My download has no azurevpnconfig.xml in the AzureVPN folder. What now?

Stop local troubleshooting. A missing azurevpnconfig file means the gateway itself is not configured for Entra ID authentication. Reinstalling the client, clearing credentials, or rebuilding the profile will not help. Escalate to the team that administers the Azure subscription.

Port 443 is open but I still get a revocation error. Why?

Certificate revocation checks travel over plain HTTP on outbound TCP 80, separately from the tunnel on 443. Block 80 and you get "The revocation function was unable to check revocation because the revocation server was offline," often shown as error 0x80092013. Allow outbound TCP 80 from the user's network and retest.

Can my team connect from iPhones or Android phones?

Not with this client. Microsoft publishes no Azure VPN Client for iOS or Android. Mobile access to internal resources needs a different approach, such as publishing the specific applications users need. Treat it as a design decision, not a support workaround.

Could a wrong timezone be causing sign-in failures?

No. Windows stores time in UTC and calculates local time from the timezone setting, so a wrong timezone alone does not break authentication. Look for what moves the UTC clock instead: a stopped w32time service, NTP blocked outbound, a failing CMOS battery, or a dual-boot setup writing local time to the hardware clock.

One user with a stale saved account is a ticket. The same failure across a dozen laptops every month is a configuration problem wearing a ticket costume, and it usually points at gateway settings, egress rules, or a fleet past its support window. LayerLogix brings 20+ years of experience and 100% Texas-based support to that cleanup, through managed IT services and identity work.

If Azure VPN tickets are a standing item in your week, call our Greater Houston office at 713-571-2390, or start with a free IT assessment, and we will follow up with someone who can walk the six checks against your environment.