Cannot connect to azure AVD, it is resolving AKAMAI domain name and IP when ping client.wvd.microsoft.com

Question

There is a single user cannot access to AVD (no matter if web or app method), when trying using

Web access, we have next error

"the connection for this site is not secure" ,"ERR_SSL_PROTOCOL_ERROR"

Using windows app: "Something went wrong" ,"we failed to fetch the subscription information..."

However, this only happens when user travel to another country and using home network (user resides in US but travel to another country sometimes).

When user travel to another country in that home network, we pinged client.wvd.microsoft.com, and it is resolving / routing a different name "e86303.dcxs.akamaiedge.net [23.50.115.145]".

When user is back home in US or even at the office, it is getting a different resolution and everything is working fine .

Even the rest of us, we are getting azurewebsites.windows.net instead akamaiedge.net

Can someone guide what can we do in this matter , because it was working 2 weeks ago and suddenly last week started to fail.

We have done a workaround meanwhile t-shooting, and in which is to add both urls in windows localhost and use any of the correct IPs and after that at least is able to work with web client, for app client, it open the session but nothing happens, any click is not working.

Answer 1

hi Jorge Garza, thanks a ton for dropping this in q&a, this one really helps uncover a weird case that hits when stuff works fine in one country and goes poof in another.

hmmm... that ERR_SSL_PROTOCOL_ERROR from client.wvd.microsoft.com? yeah that's a classic handshake fail. but not because microsoft messed something up (they rarely do, i mean come on, azure infra is a beast *-) it’s almost always something messing with the TLS chain. and aha, urs screenshots totally gave it away )

see, when users in the US or at office, client.wvd.microsoft.com resolves correctly to an azure-owned ip, something like *.azurewebsites.windows.net. all smooth, handshake happy, cert matches, session starts.

but when user's abroad ups dns flips and now it’s resolving to an akamai edge node e86303.dcxs.akamaiedge.net (ip 23.50.115.145). that ain't the right endpoint. and since that akamai endpoint isn’t meant to serve the avd web client traffic directly, ssl goes. basically wrong server answering the call, hence the error.

so what’s likely happening? some local dns or isp level transparent proxying / redirecting / cdn optimization (yep, some providers try to outsmart azure) is hijacking the dns for that client.wvd.microsoft.com domain. it’s not malicious, just annoying af.

solution time? yes it is :)

u can try set a clean dns. grab cloudflare 1.1.1.1 or google dns 8.8.8.8 in the network adapter and reboot the box. just open network & internet > change adapter > ipv4 settings > use custom dns. this avoids that shady local isp resolver.

if that doesn’t fix it, u can do a temporary workaround like u said (editing hosts file to hardcode the correct ip for client.wvd.microsoft.com) that’s decent but not ideal long-term coz azure endpoints can rotate ips. not static.

for a more 'like a pro' fix install azure network watcher in that region or check if u have a peered vpn and run connection troubleshoot tool from the azure portal to check how dns is being resolved in that location. https://learn.microsoft.com/en-us/azure/network-watcher/network-watcher-connectivity-overview

alsoooo, for completeness check if the user has some local antivirus or vpn active that’s doing ssl inspection (cough cough, kaspersky and nordvpn i’m looking at u lol )). those can also break tls or route through odd cdn nodes. u can temporarily disable and retry.

and for the app itself ( the native windows avd client) if session opens but nothing works after that, it’s prob getting session tokens from the wrong region and then failing to sync with the correct feed. try signing out fully and readding the feed after dns is cleaned up.

if it was working 2 weeks ago and then just broke suddenly... odds are some isp level change or dns optimization is happening behind the scenes. keep a log of resolved ip and cname when it fails next time just in case u need to show support what changed ))

let me know how it goes or if u want a script to auto-detect correct ip and write to hosts)))
peace

Alex

and "yes" if you would follow me at Q&A - personaly thx.
P.S. If my answer help to you, please Accept my answer

PPS That is my Answer and not a Comment