11.5 Resolving IP Address Issues in Hybrid Environments

Resolving IP Address Issues in Hybrid Environments

Microsoft lists "Resolve IP address issues in hybrid environments" as its own bullet inside the Manage IP addressing in on-premises and hybrid scenarios functional group, alongside DHCP and IPAM. It is a troubleshooting objective, and it is scored on a specific insight: the addressing rules you rely on inside a Windows Server datacenter are not the rules Azure enforces. Most hybrid IP failures are not broken hardware — they are an on-premises assumption (a full usable subnet, a broadcast domain, a DHCP server that owns the wire, an IP you can pin in the guest OS) colliding with a platform that reserves addresses, blocks broadcast, and assigns addresses itself.

Work the problem in two halves: what breaks on-premises, and what breaks in Azure.

1. On-Premises Symptoms and Their Real Causes

Conflict detection is the one server-side control worth memorizing. By default the Windows DHCP Server service does not ping an address before leasing it: ConflictDetectionAttempts is 0. You can raise it to a value from 0 through 5, and Microsoft's own guidance is to keep it at 3 or less, because each attempt adds a ping round trip to every lease and a higher value measurably slows the server.

# Read the current conflict-detection setting
Get-DhcpServerSetting -ComputerName dhcp01

# Ping each candidate address twice before leasing it
Set-DhcpServerSetting -ComputerName dhcp01 -ConflictDetectionAttempts 2

Conflict detection is a mitigation, not a fix. The durable answer is to keep static devices outside the scope's address pool or to convert them to reservations.

2. Azure Addressing Rules That Break On-Premises Assumptions

These are the facts Microsoft tests, and they are the ones administrators most often get wrong when they extend a network into Azure.

Azure reserves five addresses in every subnet — the first four and the last. In 192.168.1.0/24:

That is why capacity math differs from on-premises: a /29 is the smallest supported IPv4 subnet and yields only three usable addresses, not five or six. The largest supported IPv4 subnet is a /2. IPv6 subnets must be exactly /64.

Not every range can be used as a virtual network address space. Azure accepts the RFC 1918 private ranges and also treats the RFC 6598 shared range 100.64.0.0/10 as private address space. It rejects 224.0.0.0/4 (multicast), 255.255.255.255/32 (broadcast), 127.0.0.0/8 (loopback), 169.254.0.0/16 (link-local), and 168.63.129.16/32 (internal DNS).

Layer-2 behaviour is gone. Virtual networks are Layer-3 overlays with no Layer-2 semantics. Unicast works; multicast, broadcast, IP-in-IP encapsulation, and GRE are blocked, and UDP ports 4791 and 65330 are reserved for the host. This is the reason you cannot run an ordinary DHCP server to serve Azure VMs — DHCP by unicast (source UDP/68, destination UDP/67) is not usable. You can still run a DHCP server on an Azure VM to serve on-premises clients through a relay agent, which is exactly the hybrid nuance the exam likes.

Do not pin the private IP inside the guest OS. Microsoft's explicit warning is to avoid statically assigning an Azure VM's private IP from within the operating system; set it on the NIC's IP configuration instead (Assignment → Static). If you do configure it in the OS, it must match the address assigned to the Azure network interface or you lose connectivity to the VM. Changing the private IP on the NIC restarts the VM. Note also that you cannot reserve a private address for a VM you have not created yet, and that for Resource Manager VMs the private address does not change on stop/deallocate whether the allocation is Static or Dynamic.

3. 168.63.129.16: The Address That Explains Half of Azure "Outages"

+-------------------------------------------------------------------+
|                 168.63.129.16  (virtual public IP)                |
|            Host-node VIP - NOT subject to user-defined routes     |
+-------------------------------------------------------------------+
   |            |              |               |              |
 VM Agent    Filtered DNS   LB health      DHCP lease     PaaS guest
 "Ready"     (port 53)      probes         for the VM     heartbeat
 80/tcp                     AzureLoad-
 32526/tcp                  Balancer tag

It is a Microsoft-owned virtual public IP, identical in every region and national cloud, and it never changes. Because it is a virtual IP of the host node, it is not subject to user-defined routes — forced tunnelling a 0.0.0.0/0 route to an on-premises appliance does not break it. Communication on 80/tcp and 32526/tcp with WireServer is likewise not subject to network security groups, but it is subject to the local firewall inside the VM, which is where administrators break it. DNS traffic to it is not filtered by NSGs unless you deliberately target the AzurePlatformDNS service tag; load-balancer probes rely on the AzureLoadBalancer tag, and denying that tag makes probes fail. The address does not answer reverse DNS lookups, so an empty nslookup 168.63.129.16 is normal, not a fault.

Test-NetConnection -ComputerName 168.63.129.16 -Port 80
Test-NetConnection -ComputerName 168.63.129.16 -Port 32526
Invoke-RestMethod -Headers @{ Metadata = "true" } -Method GET `
  -Uri "http://168.63.129.16/?comp=versions"

4. Overlapping Address Space: The Classic Hybrid Dead End

The single most common hybrid addressing failure is two networks that were designed independently and both landed on 10.0.0.0/16. Microsoft is unambiguous: the virtual networks you peer must have nonoverlapping IP address spaces. There is no "prefer the local route" behaviour to fall back on — the peering simply cannot be created.

Two further peering rules cause the same "it should work" confusion:

• Peerings are not transitive. VNet1↔VNet2 and VNet2↔VNet3 does not give VNet1 connectivity to VNet3. You need an explicit peering or a hub NVA.
• Default Azure name resolution does not resolve names across a peering. Use Azure Private DNS or a custom DNS server; the addresses can be reachable while the names are not.

Remediation, in order of preference: re-address the smaller side; carve a non-overlapping range and migrate workloads into it; or, when re-addressing is genuinely impossible, terminate on a NAT-capable network virtual appliance rather than a peering. Address space on an existing peered virtual network can be resized without downtime — modify, add, or delete ranges, then sync the peers.

5. A Diagnostic Order of Operations

1. Is the address itself sane? ipconfig /all — APIPA means DHCP, a duplicate means a pool/static collision, an unexpected subnet means the wrong scope or relay answered.
2. Does the OS view match the platform view? Compare the guest's address against the NIC IP configuration in Azure. A mismatch here is the "static IP set in the OS" failure.
3. Is it routing or filtering? Check effective routes on the NIC (Get-AzEffectiveRouteTable) and effective security rules (Get-AzEffectiveNetworkSecurityGroup) before touching the guest.
4. Is it addressing or naming? Test-NetConnection <ip> succeeding while Test-NetConnection <fqdn> fails is a DNS problem — across peerings, almost always the missing Private DNS zone.
5. Is the platform channel healthy? Test 80/tcp and 32526/tcp to 168.63.129.16 before escalating.