I85PREP
⌘ K
Azure AZ-800 study materials
Azure AZ-800 study resources

Northwind - Hub/Spoke Connectivity Where One Direction Never Worked

Azure AZ-800 · Put your knowledge to work in context.

All case studies

Northwind - Hub/Spoke Connectivity Where One Direction Never Worked

Northwind connects its HQ network (10.10.0.0/16) to Azure through a route-based VPN gateway in a hub VNet, 10.100.0.0/16. Two spoke VNets, SpokeA (10.101.0.0/24) and SpokeB (10.102.0.0/24), are peered to the hub.

Spoke VMs can reach HQ file shares and domain controllers. HQ servers cannot reach anything in the spokes. The on-premises firewall's route table contains exactly one Azure route: 10.100.0.0/16 pointing at the VPN tunnel.

Northwind also wants to retire its last on-premises DNS servers for the zone private.northwind.com, which holds private endpoint records for a storage account and a SQL managed instance. HQ clients currently cannot resolve those names.

A third spoke, SpokeC, is planned as 10.10.5.0/24 because the team copied an HQ subnet template.

1. HQ cannot reach the spokes but the spokes can reach HQ. Explain the asymmetry and list the configuration changes required, in order.

Read the worked answer

Why it is asymmetric

  • Outbound traffic from a spoke VM to HQ is routed by the spoke's system routes and the peering. It works as soon as the peering exists.
  • Return traffic from HQ has two independent gates:
    1. Azure side: the spoke must be allowed to use the hub's gateway (Use remote gateway on the spoke peering, Allow gateway transit on the hub peering). Without this the spoke has no path through the gateway at all.
    2. On-premises side: the HQ firewall must have a route for the spoke prefixes. It only knows 10.100.0.0/16, so packets for 10.101.0.0/24 and 10.102.0.0/24 are dropped or sent to a default gateway.

Changes, in order

  1. Hub peering: enable Allow gateway transit. Spoke peerings: enable Use remote gateway. Both sides must agree - a one-sided setting is silently ineffective.
  2. Confirm the VPN gateway advertises the spoke prefixes to HQ (they are advertised when the spokes use the remote gateway). Verify with the effective routes on the gateway and the learned routes on the firewall.
  3. Add the spoke prefixes to the on-premises firewall route table, or rely on the advertised routes if the tunnel is BGP.
  4. Check NSGs on the spoke subnets for inbound rules from 10.10.0.0/16 - a correct route with a blocking NSG looks identical from the user's seat.

Test with Test-NetConnection from HQ to a spoke VM and check the effective routes on the VM's NIC before touching anything else.

2. What happens with SpokeC's planned address space, and what are the options?

Read the worked answer

What happens

  • 10.10.5.0/24 sits inside HQ's 10.10.0.0/16. Azure VNet peering does not support overlapping address spaces: creating the peering to the hub fails outright. Even if it were created, routing would be ambiguous - the same prefix would exist on both sides of the tunnel, and HQ would send those packets to its local subnet rather than to Azure.

Options

  1. Renumber SpokeC before deployment. Choose a prefix from the Azure supernet (for example 10.103.0.0/24) and keep a documented, enforced address plan. This is almost always the right answer; it is cheap now and expensive after workloads exist.
  2. NAT - Azure VPN gateway supports NAT rules for overlapping on-premises/Azure spaces, but this is an on-prem-to-Azure edge solution and does not rescue VNet-to-VNet peering. Do not present it as a fix for a spoke that overlaps the hub's peers.
  3. Isolate SpokeC behind an NVA or a separate connectivity subscription with no peering to HQ-routed space - high cost, limited benefit.

Prevention

  • Implement an IP address management record and, better, a policy/CI check that rejects VNet creation whose address space intersects the reserved plan. Copying a subnet template is exactly how these collisions happen.

3. Design name resolution so HQ clients can resolve private.northwind.com records before the on-premises DNS servers are retired.

Read the worked answer

The problem

  • Private DNS zone records for private endpoints are only answerable by Azure DNS. HQ resolvers have no path to them, so lookups fail or return public answers (which for a private-endpoint-enabled resource is a broken connection, since the public path is often disabled).

Design

  1. Create an Azure DNS Private Resolver in the hub VNet with an inbound endpoint on a dedicated subnet. This gives Azure DNS a private IP that on-premises can reach across the VPN.
  2. Link private.northwind.com to the hub VNet, and to every spoke VNet that hosts clients needing to resolve those records (or use a hub-based forwarding design).
  3. On the on-premises DNS servers, create a conditional forwarder for private.northwind.com pointing at the inbound endpoint IP. Do not forward . - that leaks all corporate resolution into Azure.
  4. Add the reverse path: spoke VMs needing AD names should forward to the on-premises DCs via an outbound endpoint or conditional forwarder, so resolution is symmetric.
  5. Ensure the on-premises firewall permits DNS (TCP/UDP 53) to the inbound endpoint, and that NSGs on the resolver subnet allow it.

Check before retiring anything

  • Verify the resolver is not a single point of failure: use zone-redundant where available, and confirm the tunnel path is as resilient as the DNS dependency it now carries.