The Hub And Spoke Pattern In Azure

Peerings are not transitive. Hence the pattern is :

  1. Hub vpn is connected to to Azure VPN Gateway or Express Route link that goes to on-prem
  2. Then you spoke out vpns from that hub vpn

    hub-spoke

Core Components

Security Considerations

Availability Considerations

VPN Gateway & Local Gateway

  1. Virtual Network Gateway is the termination of a network and is placed in a Gateway subnet in the VPN. Has a public ip address
  2. An Azure resource: Local network Gateway is also created. This represents the on premise gateway
  3. In the connections property of the VN Gateway (#1), the Local network gateway (#2) is hooked up.

Connecting Spokes

  1. Normally you don’t have to do anything explicit with route tables; Azure handles it automatically with System Routes. Internet calls are also handled automatically
  2. You can override System Routes with User Defined Routes (UDR). You would do this when you want your spokes to communicate. You would create UDRs in the spokes to forward traffic to a Virtual Network Appliance that resides in the hub, thus forcing all subnets to put all their outbound traffic through that appliance. This is called Service Chain
  3. Route tables are bound to subnets
  4. On the V N Appliance, you would enable IP Forwarding so that it can pass on traffic that is not destined for it self.

Private DNS Zones

When VNETs are peered, you can use a Private DNS Zone for name resolution between the vents.

  1. Create a Private Zone (powershell required: New-AzureRmDnsZone). If you have a single vnet, it will be a RegisterationVirtualNetwork. For multiple vnets, the first one will be a Registration vnet, the others will be resolution vnets
  2. Create host records for each private IP address: Name, RecordType = A, DNSRecords = IP address

Testing Connectivity

Test-NetConnection -ComputerName <ipaddress> -Port <port>