Azure P2S DNS Fails When the Resolver Is in a Peered VNet

A client can reach its own virtual network and still fail to resolve names in a peered one. Peering is not gateway transit until both sides say so.

Ping the VM and it answers; ask for its name and the client says the host is unknown. When the resolver sits in a peered virtual network rather than in the one that holds the VPN gateway, that pair of results is expected, and no amount of resolver troubleshooting changes it. What is missing is a routing contract that peering withholds by default. Two topologies look almost identical on paper, and the gap between working and broken is a pair of peering switches set the right way round.

Picture a laptop tunnelling into a gateway in VNet2, with the domain controller that serves DNS sitting in VNet1.

Two topologies, one difference

Put the resolver inside the gateway's own virtual network and the name resolves the moment the tunnel comes up. No peering setting takes part in that lookup.

Move the same resolver across a peering and the client still gets an answer from the VM while the name stays unknown. Certificate, tunnel and client are unchanged. The only thing that moved is where the resolver lives. Peering handed it a route to that address, not authority for the gateway to carry traffic there.

Side A: allow gateway transit on the gateway owner

A peering joins two virtual networks, but the join is not transitive for traffic that arrives through a gateway, and a point-to-site request arrives exactly that way. The gateway in VNet2 therefore has no standing to hand the lookup over to VNet1 until the design grants it. The grant is a switch on the peering owned by the network that holds the gateway.

Set Allow gateway transit on VNet2's peering toward VNet1. The property belongs to the peering object, not to the gateway resource, so the peering blade is where you read and change it. That is the whole of side A.

Side B: use remote gateways on the peer

The other half is the mirror image: on VNet1's peering back to VNet2, enable Use remote gateways. Turning the same flag on at both ends, or at one end only, leaves a half-built path and the original symptom untouched. Only the network with the VPN gateway allows transit, and the peer is the side that uses it.

Read both properties on both networks instead of trusting the portal blade you last opened.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

Seeing the pair side by side is the quickest way to catch a reversed setting. A peering that reports AllowGatewayTransit false on the gateway side explains the whole failure without a packet capture.

What the client must still receive

Routing is necessary and not sufficient, because the point-to-site profile also has to hand the client a DNS address that answers once transit works. The platform resolver is not that address: it answers Azure Private DNS zones linked to the virtual network, but nothing for a zone hosted on your own directory servers, which is what this deployment uses. Point a client at it and public names resolve cheerfully while the internal host stays unknown.

Query the resolver from the connected laptop before changing anything else.

nslookup dc01.corp.example 10.1.0.4

A timeout says the path is still missing. An authoritative reply pushes the problem back to the client, usually a suffix that never gets appended, so short names travel to a public resolver that cheerfully fails them.

Compare the same contract on the site-to-site side

None of this belongs to laptops in particular. Swap the client for a branch on site-to-site and the two-sided requirement returns: the branch arrives at the gateway network directly, and a service two networks away is still behind the peering.

Transit has to be granted at both peerings, and the switch that grants it lives on the peering rather than on the client type.

Before you blame the gateway

Windows keeps a resolver list per adapter, so confirm what the tunnel interface actually received before blaming the gateway.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

A negative answer outlives the routing fix in the cache, and a stale suffix list keeps sending queries somewhere that never hosted the zone. Flush, ask again, and note which server replies.

Two smaller conditions decide whether the path holds: the address spaces must not overlap, and the network security group on the resolver's subnet has to admit the client pool, which is just another source range. Prove it with an effective-route check from the VM side plus one direct query from the client, so a zone problem, a suffix problem or a filter is never mistaken for missing transit.

Allakkat attuumassuteqartut