Azure P2S VPN: Connection failing on Office Network only (Works on Home/Hotspot)

Hello Nitin Arora

1. Are there recent Azure changes to VPN Gateway IP ranges or protocols?

There have not been platform changes that would cause SSTP endpoints to stop working globally. Azure VPN Gateway P2S with SSTP still requires TCP 443, and IKEv2 connections require UDP 500 and UDP 4500. If an organization restricts outbound HTTPS only to approved destinations, those policies may block the VPN gateway’s public IP.

2. Are FQDNs required for Azure VPN Client?

   For certificate‑based SSTP, connectivity to the VPN Gateway public IP over TCP 443 is sufficient. In environments using Microsoft Entra ID authentication or OpenVPN‑based Azure VPN client, additional Microsoft endpoints (for authentication or metadata) can be contacted, but those typically relate to identity flows rather than the SSTP tunnel itself. In your configuration, failing TcpTestSucceeded directly to port 443 indicates the connection is being blocked before any higher‑level authentication is attempted.

3. Could MTU or enterprise network policies cause this?

   Yes. However, MTU issues typically appear after the connection establishes and result in packet fragmentation or unstable traffic rather than the TCP connection timeout (0x8007274c) you are seeing. The error code and test results strongly suggest the corporate network firewall or ISP filtering is preventing outbound SSTP.

Since the same VPN endpoint works correctly from other networks and your tests show TCP 443 connectivity failure only on the corporate LAN, the issue is almost certainly a firewall or outbound filtering rule on the corporate network, not a change in Azure VPN Gateway or your VPN configuration.

I hope this has been helpful!

If the above is unclear or you are unsure about something, please add a Comment below.

If these answer your question, click "Upvote" which may be beneficial to other community members reading this thread.

Hi Nitin Arora,

Thanks for reaching out in Microsoft Q&A forum,

This is a corporate network firewall/proxy blocking issue, not an Azure-side change. Your diagnostics clearly show TCP 443 to the VPN gateway times out only on the office Wi-Fi/LAN, while it works on home Wi-Fi and mobile hotspot. This is classic enterprise network filtering.

Key Facts from your Testing

• Home Wi-Fi: TCP 443 succeeds, P2S connection works
• Mobile Hotspot: TCP 443 succeeds, P2S connection works
• Office (Spectra leased line): TCP 443 times out, P2S connection fails

The tracert from the office shows traffic reaching Microsoft's network but then timing outindicating a middlebox (firewall/proxy) is dropping the SSTP tunnel initiation.

Have Azure VPN Gateway IP ranges or protocols changed (April 2026)?

No documented Azure-side changes would cause this site-specific failure. Azure P2S SSTP has consistently used TCP 443 for years. The issue is your corporate network recently started filtering SSTP traffic more aggressively.

Are there specific FQDNs beyond TCP 443, UDP 500, and UDP 4500 that the Azure VPN Client must reach?

For certificate-based P2S (your setup), the Azure VPN Client only needs:

• TCP 443 outbound to the VPN gateway's public IP for the SSTP tunnel
• (Optional) TCP 443 for certificate revocation checking (CRL/OCSP) if your CA requires it

No additional FQDNs are required for certificate authentication. The block is almost certainly on TCP 443 to the VPN gateway's public IP being flagged as "non-browser HTTPS" by deep packet inspection.

Could this be related to MTU size restrictions?

Unlikely to cause complete timeout. MTU issues typically cause the connection to establish but then traffic drops or packets fragment, not the 0x8007274c timeout you're seeing. It's still worth checking MTU once the firewall block is resolved, but it's not the root cause here.

Steps:

Immediate Actions (Request from Your Network Team)

1. Add a firewall exception for the VPN gateway's public IP on TCP 443 outbound
   • Get your Azure VPN gateway's public IP from the Azure portal (VPN Gateway > Public IP address)
   • Whitelist this IP for TCP 443 outbound on the Spectra firewall/proxy
   • Exclude it from deep packet inspection (DPI) if enabled
2. Check if SSTP is being blocked by proxy or DPI
   • SSTP looks like HTTPS but is a VPN tunnel; some enterprise proxies block non-browser TLS.
   • Ask your network team to check if "VPN over port 443" is blocked by policy
   • Temporarily test with a proxy bypass for the Azure VPN Client executable
3. Verify no SSL inspection is interfering
   • If corporate SSL inspection (MITM proxy) is enabled, it may break SSTP
   • Exclude the VPN gateway IP from SSL inspection

Client-Side Workarounds (If Network Changes Take Time)

1. Switch tunnel type to IKEv2 + OpenVPN (TCP) if supported
   • OpenVPN (TCP) may pass through more leniently than SSTP
   • Note: SSTP is retiring; Microsoft recommends migrating to IKEv2/OpenVPN
2. Use the legacy Windows built-in SSTP client instead of the Azure VPN Client
   • Some firewalls treat the Azure VPN Client executable differently
3. Test with UDP ports temporarily (if the gateway supports IKEv2)

• Ensure UDP 500 and UDP 4500 are also whitelisted

Corporate networks often update firewall/proxy policies quarterly. Common triggers include:

• A new security policy blocking "unknown VPN protocols"
• Updated DPI signatures flagging SSTP traffic
• Spectra ISP-side filtering changes (less likely but possible)
• Certificate revocation checking now being enforced more strictly

From the office machine, run:

Test-NetConnection <VPN_GATEWAY_PUBLIC_IP> -Port 443 -InformationLevel Detailed

If TCP 443 still times out, it's 100% network filtering no client tweak will fix it without firewall changes.

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.