Treat hybrid connectivity as three separate contracts: routes carry packets, DNS returns the intended addresses, and applications authenticate to the intended service. A connected VPN tunnel establishes none of those application outcomes by itself.
This guide uses a lab VMware network connected through a supported edge VPN device to an Azure hub VNet. It assumes approved Azure access and an operator responsible for the edge device. No cloud resources, firewall rules or DNS zones were changed for this article.
1. Allocate the address and name plan
List on-premises and Azure prefixes, existing peerings, advertised routes, DNS zones and management access paths. Reserve non-overlapping address space through the organisation's address-management process. Example names in this guide use example.invalid; they must be replaced with allocated lab names before execution.
Create a connection matrix:
| Flow | Source | Destination | Evidence required |
|---|---|---|---|
| Application | Lab client subnet | Lab service subnet/port | Route, security rule and correct service response |
| Azure-zone lookup | On-premises DNS | Resolver inbound endpoint | UDP/TCP DNS reachability and expected answer |
| On-premises lookup | Resolver outbound path | On-premises DNS | Route, allowed DNS traffic and authoritative answer |
| Administration | Approved operator path | Lab resources | Authentication and least required access |
Do not route storage or hypervisor management networks into the cloud merely because a broad private prefix is convenient. Review explicit advertised ranges and the return path. Microsoft's site-to-site tutorial: https://learn.microsoft.com/en-us/azure/vpn-gateway/tutorial-site-to-site-portal requires non-overlapping networks and compatible VPN-device configuration.
2. Prepare the VPN objects deliberately
Create the approved Azure VNet and workload subnets, including the dedicated GatewaySubnet required by the chosen gateway design. Select a route-based gateway SKU and availability mode supported by the edge device and project requirements. Do not copy a tutorial's region, capacity or public addresses into a real deployment.
Create the local network gateway object to represent the edge VPN endpoint and approved on-premises prefixes. Configure the matching site-to-site connection and the device-side tunnel parameters through the two owners' reviewed runbooks. Exchange authentication material through the approved secret channel, not this document.
If using active-active gateways, configure the required tunnels and routes for that topology; a device supporting only a different mode must not be treated as equivalent. Retain the selected gateway configuration and effective route evidence after deployment.
3. Prove transport before changing DNS
Select one disposable service with a known allocated IP and port. From an authorised Windows lab client, test the TCP path using the IP directly, then use the hostname only after DNS has been configured.
Get-Help Test-NetConnection -Full
Test-NetConnection -ComputerName 'app-cloud.lab.example.invalid' -Port 443 -InformationLevel Detailed
The fictional hostname becomes meaningful only after lab records exist. For the initial route test, substitute the allocated service IP. The command reference: https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection?view=windowsserver2022-ps describes the TCP test and reported source/remote information.
A successful TCP connection does not validate TLS identity, HTTP correctness or authorisation. A failed ping is also not conclusive if ICMP is intentionally blocked. Inspect effective routes, network security rules, edge policies and guest firewall/service state at the failed boundary.
4. Design both DNS directions
Use Azure DNS Private Resolver's inbound endpoint for queries entering Azure from the on-premises resolver. Use an outbound endpoint and forwarding ruleset for selected names that Azure needs resolved by on-premises DNS. These are different functions, not two names for the same gateway.
Provision the endpoints in their required dedicated delegated subnets and follow current service restrictions for the selected region. Link the relevant Azure private zones to the resolver's VNet. Create a forwarding rule for the specific on-premises suffix and link its ruleset to the intended workload VNets. Resolver endpoints and rulesets: https://learn.microsoft.com/en-us/azure/dns/private-resolver-endpoints-rulesets
On the on-premises DNS service, add a conditional forwarder for the lab Azure private suffix to the resolver's inbound address. Keep unrelated names on their existing resolution path. Avoid a catch-all forwarding rule until the complete resolution graph is reviewed.
The hybrid resolver architecture: https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/azure-dns-private-resolver shows how private zones, VNet links and on-premises forwarding work together. A VNet peering connection alone does not establish every required DNS-zone or forwarding relationship.
5. Prevent forwarding loops
Draw the actual query path for each suffix. For example: client, on-premises DNS, Azure inbound endpoint, linked private zone. Draw the reverse path separately for the on-premises suffix.
If an Azure forwarding rule sends a suffix back to an inbound endpoint, do not link that rule in a way that makes the endpoint's own VNet forward the same query back to itself. Microsoft explicitly documents this loop risk in the ruleset guidance: https://learn.microsoft.com/en-us/azure/dns/private-resolver-endpoints-rulesets.
Also review custom DNS settings on each workload VNet. A client configured to use a different resolver may never enter the ruleset path being inspected. Identify the resolver the client actually queries rather than assuming the architecture diagram is active.
6. Test names and services independently
From each side, query the opposite lab service using its full name:
Get-Help Resolve-DnsName -Full
Resolve-DnsName -Name 'app-cloud.lab.example.invalid' -Type A
Resolve-DnsName -Name 'app-site.lab.example.invalid' -Type A
Where necessary, repeat with -Server and the allocated DNS-server address to isolate a particular resolver. The Resolve-DnsName reference: https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname?view=windowsserver2022-ps documents those options.
Check the answer's address against the intended private service endpoint, and record TTL and test location. A syntactically valid response returning the public service address can still be wrong for the design. Test a deliberately absent name too, recording the expected negative response rather than accepting a broad wildcard result.
Finally use the real application client over the verified name. Check certificate hostname validation, authentication and a synthetic read/write operation. Do not bypass certificate checks because an IP-based TCP test succeeded.
7. Diagnose the failed layer
| Observation | Next boundary |
|---|---|
| Tunnel connected, IP/port test fails | Effective routes, return path, security rules and listening service |
| IP works, FQDN fails | Client resolver, conditional forwarding and zone linkage |
| DNS resolves to the wrong address | Authoritative record, private/public suffix and CNAME chain |
| One direction resolves, the other does not | Inbound versus outbound design and ruleset links |
| Intermittent failures after a change | TTL/caches, multiple DNS servers and inconsistent policy |
| TCP works but application fails | TLS identity, authentication and application dependencies |
Capture a bounded interval and compare both sides' logs. Avoid broad DNS cache flushing on shared servers as a substitute for understanding TTL and resolver selection.
Acceptance and rollback
Accept the lab only when both name-resolution directions, required service operations and expected access denials pass. Record a separately approved tunnel/path-failure rehearsal if resilience is required; one functioning tunnel is not a high-availability test.
Before changes, save the original route/DNS settings and identify an administration path unaffected by them. Reverse the specific test rules and links if the pilot fails, then verify the original service path. Deleting a gateway or replacing shared DNS servers is not a routine rollback shortcut.
Related topics: Azure disaster recovery, VMware networking and Windows file-service access.
Learning notes
- A VPN status indicator is not application acceptance.
- Resolver inbound and outbound endpoints solve opposite query directions.
- Correct DNS includes the intended address and authority, not merely a response.
Sources and review status
See the source ledger, author self-check and series index. Independent review and lab validation remain pending.