Azure point-to-site connects but no private resource responds
Connected only means the tunnel came up. Check what the gateway can carry, compare address spaces, then resolve a name and test the service itself.
Connected is a state of the tunnel, not a statement about reachability. A point-to-site client can finish IKE, receive an address, and still reach nothing, because the gateway only forwards traffic for networks the VNet already knows about. Work these five checks in order and stop at the first failure. Skipping ahead is how a DNS problem gets treated as a firewall problem for an hour.
The order matters more than the list.
Check 1: decide what the tunnel is supposed to carry
Azure VPN Gateway terminates the tunnel and forwards traffic that belongs to the VNet; it is not a general internet exit. If users expect their browsing to leave through Azure, the design is wrong before any client setting is involved. Enable split tunneling so local internet keeps using the local path, and use a NAT instance or a site-to-site tunnel when a fixed egress address is genuinely required.
Write down what the client should reach before you test anything. Without that list, every partial result looks like progress.
Check 2: compare address spaces before certificates
Overlap is judged on the wider ranges, so two networks that look different at the subnet level still collide if their parent blocks overlap. The gateway subnet has to be dedicated and large enough for the SKU, and the client address pool must not collide with the VNet or with anything reachable across a peering. Change the plan and redeploy, because adding routes to compensate produces a tunnel that works for some destinations and inexplicably not others. Provisioning does fail loudly here, which is the good case.
Authentication is the next gate. Certificate, RADIUS and Entra ID profiles are not interchangeable, and the client package differs for each.
Check 3: resolve a private name from inside
The client keeps its own resolver unless the downloaded profile carries the VNet DNS servers, and that list is embedded at download time. Add a forwarder inside the VNet, set it as the VNet DNS server, then download and import the client package again. Reusing the old package only tests the old resolver list.
Test an address first, because it separates routing from naming in a single step: Test-NetConnection 10.20.1.4 -Port 3389.
If the address answers and the name does not, query the resolver directly with Resolve-DnsName files.corp.example -Server 10.20.0.4. If both fail, the fault is not DNS and you should stop editing DNS settings. Azure platform DNS at 168.63.129.16 answers only from inside the VNet, so a client outside it cannot use that address as a resolver.
Check 4: test the service behind the tunnel
A healthy tunnel and a closed port look identical from the client. Check the guest firewall, then the network security group on the subnet or NIC, then whether the service listens on the private address rather than on loopback only. Allow the client pool as a source instead of opening a rule to the internet, and remember that SMB to Azure Files needs the private endpoint path routed through the tunnel. When a resource answers by IP but not by name, go back to check 3 rather than touching the gateway.
One table keeps the layers apart while you work:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
Check 5: record the profile before you escalate
Put the gateway type, tunnel type, authentication method and client operating system in the ticket. A certificate IKEv2 profile and a RADIUS profile fail for different reasons, and a client built for another tunnel type connects only when the gateway offers a compatible protocol.
For a small team the durable design is one VNet, one DNS forwarder and a documented split-tunnel client. If the requirement is a fixed public egress, terminate a site-to-site tunnel on a firewall you control and route internet traffic there instead of asking the point-to-site gateway to do something it was never built for.