Transitive Routing in 2025: Still Relevant, Still Causing Trouble

All code for this blog can be found here.

So this is still relevant in 2025. Having worked at Microsoft, I always believed customers were at the AI level of cloud adoption. After Microsoft and working at AHEAD, I have come to realize we are a long way away from that reality. Transitive routing still comes up because of a few different reasons and my hope is to enlighten you!

Earlier this year in my lab, one of my domain controllers (sbkWusDc02) threw this alert:

Domain controller is unable to find a PDC.This will lead to impacted user logons, unapplied group policy changes, and system time synchronization failure.

That was my wake-up call. The root cause was not Active Directory itself. It was my network design. I had two separate site to site VPNs, one for each Azure region, but I had not enabled transitive routing. As a result, my domain controllers could not replicate across regions.

What is Transitive Routing?

Transitive routing means that if network A can talk to network B, and network B can talk to network C, then A can also talk to C without routing back through on-premises or some other bottleneck.

In an Azure and VPN or Tailscale scenario, this looks like:

• VNet 1 and VNet 2 connected by a VPN or Tailscale link

• VNet 2 and VNet 3 connected by another VPN or Tailscale link

• The links are set up so VNet 1 can reach VNet 3 through VNet 2 or a hub

In short, all domain controllers and other AD-aware infrastructure across sites need stable, low latency, and secure paths to talk directly.

Why AD Replication and DC Roles Need More Than Basic Routing

Active Directory replication depends on several things:

• Name resolution (DNS) - Domain controllers must be able to resolve each other’s FQDNs.

• RPC, dynamic ports, and LDAP connectivity - It is not just about ping.

• Time synchronization - The PDC emulator is critical.

• FSMO role reachability - PDC, RID, and other roles must be accessible.

It is a common mistake to assume UDRs alone are enough. UDRs change packet forwarding but do not guarantee the service-level behaviors AD replication requires. They can also create asymmetric routing or unexpected paths that break RPC sessions. Even if packets are routed, AD Sites and Services may still choose inefficient replication paths or lose contact with the PDC emulator.

When Do You Need Transitive Routing?

My AD replication issue was the classic example, but here are the most common enterprise use cases:

1. Active Directory Replication - Domain controllers in different regions cannot replicate without direct, symmetric connectivity.

2. Hub and Spoke Architectures - Spokes often need to talk to each other through the hub for app-to-database traffic, DNS resolution, or monitoring flows.

3. ExpressRoute and VPN Coexistence - Enterprises often need workloads behind ExpressRoute and VPN to talk to each other.

4. Shared Services - Centralized DNS, logging, PKI, or identity services must be reachable from every VNet.

5. Multi Site Hybrid - Two datacenters each connect to Azure through VPN. Azure becomes the meet me point only if transit is enabled.

6. Overlay Networks - Tailscale and WireGuard make point to point easy, but multi hop traffic still requires transit.

7. Firewalls and Network Virtual Appliances - If all traffic must flow through a firewall or proxy, spokes need transit to reach each other through the appliance.

8. Kubernetes or AKS Multi Cluster Mesh - Pod to pod communication across clusters requires replication paths similar to AD.

9. Monitoring and Backup - Centralized monitoring or backup services must reach workloads across VNets.

10. Cross Cloud Architectures - VPNs between Azure, AWS, and GCP do not automatically allow cross cloud traffic. A transit hub is required.

How Transitive Routing Can Be Achieved

There are a few options for enabling transitive routing:

Approach	Pros	Cons or Considerations
VNet Peering with Gateway Transit	Clean option in Azure. Allows traffic across VNets or regions.	Must configure peering correctly and allow forwarded traffic.
Hub and Spoke Design	Centralizes routing and control.	More complexity and requires careful sizing of gateways and bandwidth.
Routing Protocols (BGP)	Dynamic propagation and robust failover.	Requires more configuration and security controls.
Mesh or Partial Mesh Peering	Ensures direct paths.	Complexity grows with number of links.
Tailscale or Overlay Networks	Easy peer connectivity with NAT traversal.	Must allow all AD replication traffic and ensure stability.

Case Study: What Went Wrong Without Transitive Routing

Imagine two my two Azure VNets, one in West US and one in East US. Each had a domain controller and a VPN back to on-premises. Without VNet peering or a hub with transit, the only available network paths are:

• West US DC to on-premises

• East US DC to on-premises

  
  

If the on-premises VPN goes down, replication between the two regions fails. Even when the VPN is up, latency can cause RPC failures. Alerts such as “Domain controller is unable to find a PDC” show up. Group Policy updates fail. Time synchronization drifts.

By adding transitive routing, for example peering West US and East US with “use remote gateway” enabled, the DCs can communicate directly. Replication stabilizes and policies apply without issue.

Drag and Drop Code for VNet Peering

Below you'll find code you can drop into PowerShell, Az CLI, Terraform, or Bicep. The Terraform and Bicep versions include variable files so you can store them in GitHub and reuse them.

PowerShell

# Variables
$rg = "AD-Networking"
$vnet1 = "vnet-westus"
$vnet2 = "vnet-eastus"

# Get the VNets
$vnetWest = Get-AzVirtualNetwork -Name $vnet1 -ResourceGroupName $rg
$vnetEast = Get-AzVirtualNetwork -Name $vnet2 -ResourceGroupName $rg

# Peer WestUS to EastUS
Add-AzVirtualNetworkPeering -Name "WestToEast" `
    -VirtualNetwork $vnetWest `
    -RemoteVirtualNetworkId $vnetEast.Id `
    -AllowForwardedTraffic `
    -AllowGatewayTransit

# Peer EastUS to WestUS
Add-AzVirtualNetworkPeering -Name "EastToWest" `
    -VirtualNetwork $vnetEast `
    -RemoteVirtualNetworkId $vnetWest.Id `
    -AllowForwardedTraffic `
    -UseRemoteGateways

Azure CLI

# Variables
rg="AD-Networking"
vnet1="vnet-westus"
vnet2="vnet-eastus"

# Peer WestUS to EastUS
az network vnet peering create \
  --name WestToEast \
  --resource-group $rg \
  --vnet-name $vnet1 \
  --remote-vnet $vnet2 \
  --allow-forwarded-traffic true \
  --allow-gateway-transit true

# Peer EastUS to WestUS
az network vnet peering create \
  --name EastToWest \
  --resource-group $rg \
  --vnet-name $vnet2 \
  --remote-vnet $vnet1 \
  --allow-forwarded-traffic true \
  --use-remote-gateways true

Terraform

variables.tf

variable "resource_group_name" {
  description = "Resource group containing the VNets"
  type        = string
}

variable "vnet_west_name" {
  description = "Name of the West US VNet"
  type        = string
}

variable "vnet_east_name" {
  description = "Name of the East US VNet"
  type        = string
}

terraform.tfvars

resource_group_name = "AD-Networking"
vnet_west_name      = "vnet-westus"
vnet_east_name      = "vnet-eastus"

main.tf

data "azurerm_virtual_network" "vnet_west" {
  name                = var.vnet_west_name
  resource_group_name = var.resource_group_name
}

data "azurerm_virtual_network" "vnet_east" {
  name                = var.vnet_east_name
  resource_group_name = var.resource_group_name
}

resource "azurerm_virtual_network_peering" "west_to_east" {
  name                      = "WestToEast"
  resource_group_name       = var.resource_group_name
  virtual_network_name      = data.azurerm_virtual_network.vnet_west.name
  remote_virtual_network_id = data.azurerm_virtual_network.vnet_east.id
  allow_forwarded_traffic   = true
  allow_gateway_transit     = true
}

resource "azurerm_virtual_network_peering" "east_to_west" {
  name                      = "EastToWest"
  resource_group_name       = var.resource_group_name
  virtual_network_name      = data.azurerm_virtual_network.vnet_east.name
  remote_virtual_network_id = data.azurerm_virtual_network.vnet_west.id
  allow_forwarded_traffic   = true
  use_remote_gateways       = true
}

Run with:

terraform apply -var-file="terraform.tfvars"

Bicep

main.bicep

@description('Name of the resource group')
param resourceGroupName string

@description('Name of the West US VNet')
param vnetWestName string

@description('Name of the East US VNet')
param vnetEastName string

resource vnetWest 'Microsoft.Network/virtualNetworks@2023-09-01' existing = {
  name: vnetWestName
}

resource vnetEast 'Microsoft.Network/virtualNetworks@2023-09-01' existing = {
  name: vnetEastName
}

resource westToEast 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
  name: 'WestToEast'
  parent: vnetWest
  properties: {
    remoteVirtualNetwork: {
      id: vnetEast.id
    }
    allowForwardedTraffic: true
    allowGatewayTransit: true
  }
}

resource eastToWest 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
  name: 'EastToWest'
  parent: vnetEast
  properties: {
    remoteVirtualNetwork: {
      id: vnetWest.id
    }
    allowForwardedTraffic: true
    useRemoteGateways: true
  }
}

main.bicepparam

using './main.bicep'

param resourceGroupName = 'AD-Networking'
param vnetWestName = 'vnet-westus'
param vnetEastName = 'vnet-eastus'

Deploy with:

az deployment group create \
  --resource-group AD-Networking \
  --template-file main.bicep \
  --parameters main.bicepparam

Best Practices for Adding Transitive Routing with AD

• Map subnets to the right sites in AD Sites and Services

• Plan IP ranges to avoid conflicts across regions

• Enable VNet peering with gateway transit or use a hub and spoke design

• Use BGP where possible for dynamic route propagation

• Ensure NSGs and firewalls allow RPC, LDAP, Kerberos, DNS, and time sync

• Monitor with repadmin, dcdiag, and nltest

• Keep the time sync hierarchy correct, with the PDC emulator syncing externally and other domain controllers syncing to it

  
  

Tailscale and Overlay Networks

Overlay networks like Tailscale make it easier to connect peers across NATs and different locations. For AD replication, make sure:

• The overlay allows all required ports

• Latency is stable

• Paths are symmetric

• DNS resolution works across the overlay

  
  

Overlay networks can help, but they must be carefully integrated into the routing model.

References

• Spoke to spoke networking in Azure

• Routing issues with S2S VPN and peered VNets

• Deploy AD DS in an Azure Virtual Network

Conclusion

Transitive routing is still a real challenge in 2025. It is required for multi region AD replication, hub and spoke designs, hybrid connectivity, and even overlay networking. Without it, domain controllers may fail to replicate or lose contact with the PDC emulator. UDRs alone are not enough.

The solution is to peer your VNets with gateway transit or build a hub and spoke topology. With PowerShell, Az CLI, Terraform, and Bicep you have multiple ways to configure this consistently across environments. By adding variable files, you make the configuration enterprise ready for GitHub and reusable in future projects.