Why a Private Endpoint Still Answers With a Public Address

The laptop connects, the tunnel reports itself as up, and the storage account still refuses every request. The private endpoint exists, the route to its subnet exists, and the name either answers with a public address or fails to resolve. Nothing is wrong with the tunnel: the client was never told which server should answer for that name. Follow the query outward and the gap becomes obvious.

Start at the client's resolver

Ask the client which server it queries while the tunnel is up. A point-to-site profile supplies that address, and a profile that supplies nothing leaves the operating system to fall back on the adapter defaults.

Public resolvers have no view of a private zone, so they answer from the internet, which is exactly their job. The first check is therefore the resolver address in use, not the tunnel and not the endpoint.

Read what the answer actually is

Resolve the service name and read the address that comes back. A public answer means the query reached a server that cannot see the zone. No answer means the name exists only privately and nothing the client can reach holds it.

Those two outcomes produce similar application errors and belong to different owners. One is a resolver selection problem, the other is a missing zone link.

A hosts entry proves the path, then lies

Putting the endpoint address in the local hosts file is the quickest way to prove that the tunnel and the service firewall already work. If the request succeeds with that entry, only name resolution is broken. It is also a per-machine edit that covers exactly one name.

It does not help the second account, the second endpoint or a colleague, and it breaks without warning when the endpoint is recreated at a new address.

Worse, it makes your machine behave differently from everyone else's, which is how a resolver fault survives a week of investigation. Use it to confirm the path, then take it out and fix the cause.

Link the zone and hand out a resolver

Two conditions have to hold at once. The private zone must be attached to the virtual network where the endpoint lives, and the client must send its queries to a server that can read that zone. A DNS Private Resolver inbound endpoint provides such an address inside the network and answers queries arriving over the tunnel. Put that address in the VPN profile and add the private suffix the client should apply.

An on-premises resolver already in place can reach the same outcome through a conditional forwarder aimed at the zone.

Network rules on the resolver count as much as routing does. If the inbound rule excludes the VPN client range, queries time out rather than returning a wrong answer. That timeout is what sends people back to a route table where nothing is wrong.

Check name, port and identity in order

Work in order: resolve the name, confirm the answer is private, open the port, then make an authenticated request. Each stage has its own owner and its own failure signature.

A private answer followed by a timeout points at a route or a firewall. A public answer points at the resolver. A completed connection that returns an identity error belongs to the service.

One more failure belongs on this list. A service firewall that allows a client address stops matching when the pool hands that address to another session after a reconnect. Read the caller address the service recorded rather than the one the client believes it has. The two disagree more often than people expect. The Azure DNS Private Resolver guidance covers the zone link and forwarding arrangement.