Azure VPN Client fails to connect from home but works from the IBM office

Because the same Windows 11 client and VPN profile work from the IBM office, capture matching client and gateway diagnostics from home and office before changing the client again; this will show whether the home attempt reaches Azure VPN Gateway or is rejected by an IP/location-dependent control.

1. Compare Azure VPN Client diagnostics

From each network—first home, then IBM office:

1. Open Azure VPN Client.
2. Select … next to the connection.
3. Select Diagnose → Run Diagnosis.
4. Record the results for:
   • Internet Access
   • Client Credentials
   • Server Resolvable
   • Server Reachable
5. Open the status-log panel using the arrows at the lower-right and save the timestamps and red error messages.
6. Select … → Diagnose → Show Logs Directory, then copy the logs for your VPN administrator. Microsoft documents these exact diagnostic and log-collection steps.^1^

Interpret the comparison as follows:

• Server Resolvable fails only at home: investigate the home/ISP DNS path.
• Server Reachable fails only at home: investigate filtering, proxying, or routing between the Egyptian source network and the gateway endpoint.
• All tests pass but the tunnel fails: inspect the gateway log and Entra sign-in result below.
• The home attempt never appears in the gateway log: traffic is being stopped before reaching Azure.

Your mobile hotspot is only an independent test if it exits through a different provider/ASN. If it also uses TE Data or the same upstream route, both tests can fail for the same network reason.

2. Check whether the request reaches Azure VPN Gateway

Ask an administrator to enable the VPN gateway’s P2SDiagnosticLog in Azure Monitor diagnostic settings, reproduce one failed home attempt and one successful office attempt, and query the associated Log Analytics workspace:

AzureDiagnostics
| where Category == "P2SDiagnosticLog"
| where TimeGenerated > ago(2h)
| project TimeGenerated, OperationName, Message,
          Resource, ResourceGroup
| sort by TimeGenerated desc

For OpenVPN with Entra authentication, this log can show these stages:

• Connect request received
• AAD authentication succeeded
• Connection successful

Microsoft documents that P2SDiagnosticLog covers P2S OpenVPN and records those connection stages.^2^

The result determines the next action:

• No home Connect request received: focus on the home ISP/upstream path. Provide the ISP with the failed timestamp, destination VPN hostname/IP, and client diagnostic result. Test through a genuinely different ISP if available.
• Request received and Entra authentication succeeds, but no successful connection: the gateway-side message is the primary failure evidence. Compare it directly with the successful office sequence and open an Azure support request if it does not identify a configurable cause.
• Connection successful appears on the gateway but the client reports Error 628: investigate the Windows/client network stack or local filtering. Because Windows was already reset and the client reconfigured, avoid repeating those actions unless the logs identify a client-side failure.

Microsoft Entra authentication for this configuration uses OpenVPN and Azure VPN Client; OpenVPN is TLS-based and commonly traverses firewalls using outbound TCP 443.^3^

3. Check location-based access controls

The Egypt-versus-Netherlands public-IP difference can matter if the customer has Conditional Access or another security control based on public IP, country, or trusted network. It does not by itself prove that the ISP is blocking the tunnel.

Ask the customer’s Entra administrator to:

1. Open the Microsoft Entra admin center → Entra ID → Monitoring & health → Sign-in logs.
2. Find the home attempt using its exact timestamp.
3. Open the entry and inspect Conditional Access, Location, and the final sign-in status.
4. Compare it with the successful IBM-office attempt.
5. Review Entra ID → Conditional Access → Named locations for:
   • Egypt or unknown locations being blocked.
   • The IBM public range being explicitly trusted.
   • A policy that applies outside corporate locations.

Conditional Access is evaluated after first-factor authentication, so seeing the authentication prompt succeed does not by itself rule out a location-based policy. Entra determines network location from the public address and named locations can represent IP ranges or countries.^4^

Do not add a residential IP as trusted merely to test. Microsoft recommends confirming that an address belongs to the intended organization before adding it as a trusted named location.^5^

4. Gateway configuration fallback

A general Audience, Issuer, Tenant, tunnel-type, or profile mismatch is less likely because this exact client works from the office. Check these only if gateway logs show an authentication/configuration failure or other users also fail:

• Virtual network gateway → Point-to-site configuration
• Tunnel type: OpenVPN (SSL)
• Authentication type: Microsoft Entra ID
• Audience, Issuer, and Tenant values match the client-registration model
• Client profile was generated after the latest gateway change

An incorrect Audience can allow the interactive authentication step yet prevent connection completion.^6^

The most useful evidence to share next is the home and office Run Diagnosis output, matching client status-log excerpts, the gateway P2SDiagnosticLog rows for those timestamps, and the Entra sign-in result—without account identifiers or tokens.

References

1. Troubleshoot Azure VPN Client
2. Troubleshoot Azure VPN Gateway using diagnostic logs
3. About Point-to-Site VPN
4. Conditional Access: Network assignment
5. Monitor and troubleshoot continuous access evaluation
6. Azure Client VPN does not connect - Microsoft Q&A