Hub can't reach a new subnet in a spoke
vm-hub can't reach vm-new on 443, though vm-spoke1 still works.
- Get vm-hub reaching vm-new on 443
- Keep vm-hub reaching vm-spoke1 on 443broken
Background
vnet-spoke1 is peered with vnet-hub. It ran out of room, so last week someone added the range 10.11.0.0/16 to it and built subnet-new, with vm-new (10.11.1.4) running a new service on 443. vm-hub (10.0.1.4) calls that service, but can't reach vm-new at all. vm-spoke1 (10.1.1.4) in the old range still works with the hub, and the peering shows Connected on both sides. Working means vm-hub reaches both VMs on 443.
- 1See it fail
Prove the problem yourself before you change anything. Reports are often wrong.
VM commands forVMsssh vm-hubWhat's this?
Opens a shell on vm-hub, so the next commands run on that VM. In this lab it's a shortcut. In real Azure you'd connect through something like Azure Bastion, or SSH to an address you can reach.
nc -zv 10.11.1.4 443What's this?
netcat, a standard Linux tool. Tries to open a TCP connection and reports whether it worked.
-zonly check whether the port answers. Send no data-vprint the result in words10.11.1.4where to connect443the port to try
Ticks off when the test runs on vm-hub.
- 2Find where it stops
- 3Name the cause
- 4Fix it and test again
- 5Explain it
Sources on Microsoft Learn (3)
?
- Resource group, the outer dashed frame
- Virtual network, with its address space top right
- Subnet, with range and usable IPs (5 reserved)
- Network security group. A small shield on a VM's NIC means the NIC has one too
- Route table on the subnet
- VM Appliance Private endpoint
- Peering Connected Initiated or access off
- Goal working Goal broken, X marks where it stops
- Private DNS zone, dotted lines go to linked VNets
- Orange pulse: what your last command changed. Drag to pan, Ctrl and scroll to zoom.
vm-hub → vm-new:443should work: not working