Hub and spoke options

Public Beta

Hub and Spoke Support for Azure HVNs is currently in Public Beta

This documentation focuses on Azure peering and the additional configurations for advanced network topologies, commonly referred to as hub-and-spoke.

For hub-and-spoke networking in Azure, additional settings must be enabled on the HVN Peering Connection and specific routing configurations must be added to the HVN and any other route tables used by applications communicating with HCP.

Supported network topologies

A network virtual appliance (NVA) topology is composed of a central hub network with an NVA such as Azure Firewall or 3rd party router and multiple spoke networks connected via Virtual Network Peering or on-premises networks connected via ExpressRoute or VPN.

This topology is one of the architectures recommended by Microsoft for centrally managing transitive routing between spoke virtual networks and on-premises networks.

Diagram showing a HVN peered with Azure hub network

Peering Connection Configuration

Enable hub-and-spoke configuration:

Set "Traffic forwarded from remote virtual network" to Allow
Set "Allow remote gateways" to Disallow

Screenshot of HCP Peering Connection UI showing "Traffic forwarded from remote virtual network" set to Allow
and "Allow remote gateways" set to Disallow.

Refer to Peering connections for more details about configuration of HVN Peering Connections.

Routing Configuration

Define one or more HVN Routes for all CIDR Ranges that HCP Vault Dedicated needs to reach.

Configure the HVN Peering connection for the hub-and-spoke NVA topology:

Set "Next Hop Type" to Virtual Appliance
Set "Next Hop IP" to your NVA IP Address.

The route table(s) used by the NVA for routing rules will need to be configured with a route to the HVN. Each subnet within a given Spoke Virtual Network and any on-premises network routers will also need to have a route defined to reach the HVN.

Refer to Routes for more details about configuration of HVN Routes and for the specific route patterns required.

VPN Gateway Routes

Azure VPN Gateways support static or dynamic routes. HVNs only support static route configurations by default. If dynamic route propagaton via BGP is required without a Network Virtual Appliance, reach out to HashiCorp Support prior to creating your HVN and HCP Vault Dedicated cluster.

A VPN gateway topology is composed of a central hub network and multiple spoke networks connected via Virtual Network Peering and a VPN Virtual Network Gateway.

This topology can be used to transitively route traffic between spoke virtual networks, but is not recommended by Microsoft. Diagram showing an HVN peered through a hub virtual network with a VPN Virtual Network Gateway as the transitive routing appliance

Peering Connection Configuration

Enable hub-and-spoke configuration:

Set "Traffic forwarded from remote virtual network" to Allow
Set "Allow remote gateways" to Allow

Screenshot of HCP Peering Connection UI showing "Traffic forwarded from remote
virtual network" set to Allow and "Allow remote gateways" set to
Allow.

Refer to Peering connections for more details about configuration of HVN Peering Connections.

Routing Configuration

Network Security Groups

When using Dynamic Routes, Static HVN Routes are still needed to configure the HVN Network Security Groups, but the routes themselves will be ignored by the gateway.

Define one or more HVN Routes for all CIDR Ranges that HCP Vault Dedicated needs to reach.

Configure the HVN Peering connection for the hub-and-spoke NVA topology:

Set "Next Hop Type" to Virtual Network Gateway

Screenshot of HCP Route UI showing Next Hop Type set to Virtual Network Gateway.

Each subnet within a given Spoke Virtual Network and any on-premises network routers will need to have a route defined to reach the HVN.

Refer to Routes for more details about configuration of HVN Routes and for the specific route patterns required.

ExpressRoute Gateway Routes

Azure ExpressRoute Gateways only support dynamic route propagation via BGP. HVNs only support static route configurations by default. If using an ExpressRoute Gateway without a Network Virtual Appliance, reach out to HashiCorp Support prior to creating your HVN and HCP Vault Dedicated cluster.

An ExpressRoute gateway topology is composed of a central hub network and multiple spoke networks connected via Virtual Network Peering and an ExpressRoute Virtual Network Gateway.

This topology can be used to transitively route traffic between spoke virtual networks, but is strongly discouraged by Microsoft. Diagram showing an HVN peered through a hub virtual network with an ExpressRoute Virtual Network Gateway as the transitive routing appliance

Peering Connection Configuration

Enable hub-and-spoke configuration:

Set "Traffic forwarded from remote virtual network" to Allow
Set "Allow remote gateways" to Allow

Refer to Peering connections for more details about configuration of HVN Peering Connections.

Routing Configuration

Network Security Groups

When using Dynamic Routes, Static HVN Routes are still needed to configure the HVN Network Security Groups, but the routes themselves will be ignored by the gateway.

Define one or more HVN Routes for all CIDR Ranges that HCP Vault Dedicated needs to reach.

Configure the HVN Peering connection for the hub-and-spoke ExpressRoute Gateway topology:

Set "Next Hop Type" to Virtual Network Gateway

Refer to Routes for more details about configuration of HVN Routes and for the specific route patterns required.

Additional Resources

NVA Topology Setup Example with Terraform Provider for HCP and AzureRM