Ensuring Success with Azure VPN: Verification Elements for Hub-Spoke Topology

Introduction

If you’re working with Azure VPN, you may have encountered some challenges or issues when configuring your network. In this article, we’ll go over a checklist of important elements to verify when working with Azure VPN in a hub-spoke topology. This information can save you time and help ensure that your configuration is correct.

Understanding the Architecture

The first step in verifying your Azure VPN configuration is to understand the architecture you’re working with. In this article, we’ll focus on the standard hub-spoke topology. In this topology, you have one virtual network (the hub) with multiple spokes connected to it. You’ve also configured a VPN connection to your on-premises network.

Now that you have your VPN connection set up, you need to make sure that the configuration in the topology is correct so that workloads in the spokes can reach your on-premises network and vice versa. To do this, you’ll need to address several common resources that network traffic will pass through.

  • On-prem
  • Local network gateway
  • VPN Gateway
  • VPN Subnet
  • Network Security Group for the VPN Gateway
  • Route Table for the VPN Gateway
  • Firewall
  • Firewall subnet
  • Route Table for the firewall subnet
  • Peering from the hub to the spoke
  • Peering from the spoke to the hub
  • Spoke subnet
  • Route Table for the spoke subnet
  • Network Security Group for the spoke subnet

In most cases, you’ll want to use BGP (Border Gateway Protocol) when working with Azure VPN. There are several reasons for this, including compatibility with ExpressRoute (which only supports BGP) and the ability to automatically update routes without having to manually add IP addresses to the local network gateway.

With that in mind, let’s assume that our topology includes one hub, one spoke, and a firewall in the hub network where all network traffic should be routed through. We also want to enable BGP and use a route-based VPN gateway. If you don’t want to use BGP, you can ignore the BGP-related elements on the VPN gateway and local network gateway.

Verification Checklist

Here’s a simple checklist that you can use to verify that your resources are configured correctly:

  • Local network gateway: Turn on BGP and configure it. Add the BGP peering address to the address space(s) under configuration. This ensures that routes from your on-premises network will be populated in Azure.
  • VPN Gateway: Turn on the Configure BGP setting
  • Network Security Group for the VPN Gateway: Ensure that the NSG allows communication between your on-premises network and Azure.
  • Route Table for the VPN Gateway: Turn on “Propagate gateway routes” under configuration. Add routes to each spoke to force traffic through the firewall.
  • Firewall: Open up for BGP communication
  • Route Table for the firewall subnet: Turn on “Propagate gateway routes” under configuration.
  • Peering from the hub to the spoke (this can be tricky since the azure portal shows two different views – not sure why.
    • This is if you have checkboxes
      • Allow access to remote virtual network
      • Allow traffic to remote virtual network
      • Allow traffic forwarded from the remote virtual network (allow gateway transit)
    • This is if you have radio buttons
      • Traffic to remote virtual network: Allow
      • Traffic forwarded from remote virtual network: Allow
      • Virtual network gateway or route server: Use this virtual network gateway or route server
  • Peering from the spoke to the hub (this can be tricky since the azure portal shows two different views – not sure why)
    • This is if you have checkboxes
      • Allow access to remote virtual network
      • Allow traffic to remote virtual network
      • Use remote virtual network gateway or route server
    • This is if you have radio buttons
      • Traffic to remote virtual network: Allow
      • Traffic forwarded from remote virtual network: Allow
      • Virtual network gateway or route server: Use the remote virtual network’s gateway or route server
  • Route Table for the spoke subnet: Turn off “Propagate gateway routes” under configuration.

Summary

This article provides a checklist for verifying important elements when working with Azure VPN in a hub-spoke topology. The verification checklist covers resources such as the local network gateway, VPN gateway, network security group, route table, firewall, and peering. This can help ensure your Azure VPN configuration is correct and hopefully save you some time.

Legg igjen en kommentar