In this blog post, we’ll be:
- configuring a virtual network topology in Azure in the “hub and spoke model”
- deploying an example resource (a Key Vault) in our spoke network
- restricting access to the Key Vault using a private endpoint connection so that it is only accessible inside the vnet
- configuring a DNS forwarder running Debian + Unbound in the hub network for resolving the private DNS name of the Key Vault
- configuring a Basic SKU Virtual Network Gateway
- configuring a Windows client to connect to the Basic VPN Gateway in a point-to-site configuration so it has access to the Key Vault through the private endpoint
Why?
A hub and spoke network with private endpoints for restricting access to various Azure PaaS resources is a fairly common architecture, but there are a few parts of it that lead to unnecessary costs: namely the PaaS private DNS resolver and the Virtual Network Gateway in its non-Basic SKUs, such as VpnGw1.
The primary purpose of this post is to document how I’ve achieved this architecture using the Virtual Network Gateway Basic SKU, which saves ~£80/month over the VpnGw1 SKU. It also saves the PaaS private DNS resolver costs by using a lightweight VM.
Create hub network
We’ll start by creating our “hub” network, called vnetHSTestConnectivity in my case.
We’ll be using the 172.16.0.0/24 range for this network.
