Azure P2S VPN Can't Resolve a Private Endpoint Name

You connect the point-to-site tunnel, ping the private address, open the app, and get a 403 or a certificate error instead. Both symptoms point at DNS, but they are different faults: one means the client resolved the public address, the other means it resolved the private address and then offered a name the certificate does not cover. Work the checks below in order and stop at the first failure, because a hosts entry or a cached answer can make every later check pass for the wrong reason. I keep this order in a text file next to my VPN profiles, since the fix changes nothing about the tunnel and everything about what the client knows.

Start with the address the client actually gets

Ask the resolver directly instead of trusting the application. On Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net shows which view the client received. A public answer means nothing downstream will reach the endpoint; the endpoint private address means DNS is finished and the next check is the connection itself.

A private endpoint does not rename the service. The account or app keeps its ordinary fully qualified name, and the endpoint only changes the address that name resolves to for clients inside the virtual network. That is why the same hostname resolves privately from a VM in the network and publicly from a laptop that was never given the private view.

Check the zone, its link and the record before the tunnel

Three conditions have to hold together: the private zone exists, it is linked to the virtual network where the VPN gateway and the clients enter Azure, and it holds an A record for the endpoint pointing at the private address. Link the zone to an unrelated network and the gateway keeps resolving the public record while everything about the tunnel still looks healthy.

Zone names belong to services, not to private links in general. App Service normally uses privatelink.azurewebsites.net, storage and SQL have their own namespaces, and borrowing another service zone produces a zone that exists and answers nothing useful.

Give the client a resolver it can actually reach

168.63.129.16 answers from Azure virtual machines and is not a DNS server for a laptop on the far side of a point-to-site tunnel. The client needs a resolver reachable through the tunnel: an Azure DNS Private Resolver inbound endpoint, a forwarder inside the virtual network, or DNS server entries carried in the VPN client profile so the client asks the virtual network directly.

A configured but unreachable resolver behaves exactly like no resolver, and the symptom is a timeout rather than a wrong answer, which is why it gets misread as a firewall problem. Test it with a query the tunnel is supposed to carry, not with a public name that would succeed over the local link anyway.

If you forward rather than push settings, forward the namespace the private zone owns, privatelink.azurewebsites.net rather than all of azurewebsites.net. A conditional forwarder that swallows the whole parent suffix sends every lookup for the service to Azure, including the ones that should stay local.

Use the name the certificate was issued for

Once the address is right, the second fault surfaces. Storage and App Service publish a privatelink alias, and that alias is not necessarily the name in the certificate. An AzCopy upload addressed to privatelink.blob.core.windows.net failed validation; the same upload to <account>.blob.core.windows.net/<container> resolved to the private address and passed, so it stayed on the private path without an override.

The rule holds in a browser and for App Service too: connect with the hostname the certificate covers and let DNS supply the private address. Do not reach for a validation bypass, which turns a naming mistake into a security regression. A successful ping proves the route and says nothing about the name inside the handshake, which is why these stay separate checks.

A four-step order that isolates each layer

1. Confirm the VPN client holds an address from the point-to-site pool and has a route to the endpoint private address.
2. Resolve the exact name the application uses and compare the answer with the endpoint address.
3. Open a TCP connection to the endpoint on the service port, then read the certificate name presented on that connection.
4. Only now test authorization, because a working path and a valid certificate still do not grant access to the resource.

A connection refused while the address is correct points at the network security group or the private endpoint connection state, not at DNS, so check those before editing resolver settings again. A TLS name mismatch sends you back to the hostname in the URL and the certificate subject. Keep the resolution output, the certificate name and the exact URL together; those three values explain most of these cases without touching the gateway.

Use a VM inside the virtual network as a control. If the name resolves privately there and publicly from the tunnel, the zone and the record are correct and the only difference is the client resolver path, which is faster to confirm than another pass over the endpoint configuration.

Clients also cache. A record that answered publicly ten minutes ago keeps answering after you fix the zone, so flush before you retest. On Windows, ipconfig /flushdns clears the client cache; name resolution policy rules persist, decide which suffix goes to which server, and can keep sending the namespace to the resolver you just replaced.

Where a hosts entry belongs

Adding the endpoint address to a hosts file is a good diagnostic and a poor design. It proves the name-to-address mapping is the missing piece and lets you test everything after that step, but it is invisible to your users, breaks when the endpoint address changes, and hides the zone that should be answering.

A leftover test entry is worse than a stale cache, because it can make the fixed path look broken or the broken path look fixed depending on the direction of the error. Remove it before the final run and resolve with the production resolver only.

Short names need a search suffix and fully qualified names do not, so test the fully qualified name first, then decide whether the workflow needs a suffix pushed through the client profile. Microsoft documents the per-service zone names and record shapes in its private endpoint DNS guidance; read the entry for your service instead of copying a zone from another one.