Your VPN does not make Cosmos DB private on its own
A VPN gets your laptop onto the network, not inside the database. See what the private endpoint, DNS zone, connection mode and account access must do.
You connect the laptop to the VNet through a VPN, open the Cosmos DB account URL, and the request still leaves over the public internet. The tunnel did its job. What it did not do is create a private endpoint, publish the private DNS record, or turn off public access, because those are three separate changes to the account rather than properties of your network connection. This example uses Azure Cosmos DB for NoSQL, a private endpoint in a VNet, and a laptop connected to that VNet by VPN, and it keeps the application's address unchanged.
The myth: being on the VPN makes the database private
Being on the VNet only means your packets can reach private addresses in that VNet. It says nothing about where the account name resolves, and it says nothing about whether the account still accepts public traffic.
A private endpoint is a separate resource with its own address, its own approval step, and its own DNS wiring. Until it exists and is approved, the name resolves to the public endpoint and your traffic goes there regardless of the tunnel.
What actually makes the name resolve privately
Keep the SDK's normal account endpoint, something like https://ACCOUNT.documents.azure.com. Private DNS should resolve that name through the Private Link chain to the endpoint's private addresses. Do not replace it with a numeric URL and disable certificate checks, because that trades a DNS problem for a security problem.
| Example choice | Value |
|---|---|
| Cosmos API | NoSQL |
| Private endpoint subresource | Sql |
| Private DNS zone | privatelink.documents.azure.com |
| SDK connection mode | Gateway |
Those values are specific to the NoSQL API. Other Cosmos APIs are not interchangeable entries in the same example, and copying the subresource name from a different API produces an endpoint that never resolves.
Create and approve the endpoint through the authorized Azure workflow, then use its private DNS zone-group integration. The laptop needs a resolver that can answer that zone, either directly or through approved forwarding, and a VPN client route to each relevant endpoint address.
A private endpoint can have more than one address, including global and regional entries. Maintain the DNS integration when the account's regions change instead of pinning a single address in a hosts file, and remember that an answer from an unrelated public resolver proves nothing about the private path. If you forward DNS through a hub, confirm the forwarder answers before you debug the client. A stale forwarder returns the public answer, which looks exactly like a missing endpoint.
Gateway mode and Direct mode are not interchangeable
Gateway mode sends service requests over HTTPS on TCP 443. That is why a 443-only firewall policy works for it and why this example chooses it deliberately.
Direct mode over Private Link has different connectivity requirements, including a wider TCP port range that the account documentation lists. A policy written for Gateway mode must not be silently reused for a Direct-mode client, or the SDK will connect and then hang on the first data operation.
Pick one mode, write it down with the account, and make the network policy match it. Teams that switch modes during troubleshooting usually end up with a firewall rule set that satisfies neither.
Turning off public access is a separate switch
If the account should be private-only, disable public network access through the account's supported setting and verify the result. Do not treat the existence of a private endpoint as the complete access decision, because an account with a private endpoint and public access enabled still answers on the internet.
Verify from outside the VPN as well as inside. A request from a network that should be excluded is the test that proves the setting took effect, and it is the test most change windows skip.
Reachability is not permission
A permitted SDK operation from the VPN laptop is the acceptance test, using the normal account URL and the intended identity. VPN reachability does not grant Cosmos data permissions; the data plane checks its own roles or keys.
Then run the denials: a different identity, and a network path that should no longer reach the account. If either succeeds, the boundary you documented is not the boundary you built.
Write down four facts when you finish: the endpoint's private addresses, the DNS zone that answers for the account name, the connection mode with its port requirements, and whether public access is disabled. Those four explain the setup to the next person, and each one fails independently.