Skip to main content
Welcome — this guide shows how to configure an Azure VPN Gateway. It covers required prerequisites (GatewaySubnet), key deployment choices, and a short portal demo using a PowerShell script. Follow the sequence below to create a robust VPN Gateway suitable for site-to-site (S2S) and point-to-site (P2S) scenarios and for hub-and-spoke architectures. At a high level, the steps are:
  1. Create a dedicated subnet named GatewaySubnet in your virtual network.
  2. Deploy the VPN Gateway resource into that subnet.
  3. Configure the appropriate connections (site-to-site or point-to-site) depending on your scenario.
If you use a hub-and-spoke architecture, place the GatewaySubnet in the hub VNet and enable gateway transit for spokes as needed. GatewaySubnet is a special, required subnet — Azure will not create a gateway without it.
A presentation slide titled "Configuring VPN Gateway" showing a two-step horizontal timeline: 01 "Create Gateway Subnet" and 02 "Create VPN Gateway" with turquoise numbered markers. The slide includes a small "© Copyright KodeKloud" notice at the bottom left.

​
1) Create the GatewaySubnet (required)

The GatewaySubnet is mandatory for any Azure VPN Gateway. Follow these rules when creating it:
  • Name the subnet exactly GatewaySubnet (case-insensitive, no spaces). Azure requires this exact name to host the gateway.
  • Reserve this subnet solely for the VPN Gateway; do not deploy virtual machines or other resources into it.
  • Size the subnet large enough for scaling. Microsoft recommends at least a /27 prefix to allow multiple gateway instances.
  • Do not attach Network Security Groups (NSGs) or user-defined route (UDR) tables to the GatewaySubnet — Azure manages the gateway network rules.
Name the subnet exactly “GatewaySubnet” and reserve it solely for the VPN Gateway. Avoid attaching NSGs or custom route tables to this subnet.
The image is a slide titled "Creating a Gateway Subnet" that lists guidelines (Subnet Naming, Dedicated Purpose, Subnet Size, and No NSG or Route Table Needed) alongside an Azure portal "Add subnet" configuration pane. It highlights that the subnet must be explicitly named "GatewaySubnet," reserved for a VPN gateway, and use a /27 or larger CIDR block.

​
2) Create the VPN Gateway resource

When you create the VPN Gateway, choose options that match your connectivity and scale requirements. Key configuration decisions:
  • VPN type: route-based (recommended) or policy-based (legacy). Route-based supports dynamic routing (BGP) and is required for features like Azure Route Server integration.
  • SKU: Select a gateway SKU (for example, VpnGw1, VpnGw2, VpnGw3). SKU determines tunnel count and throughput — pick based on expected traffic and the number of concurrent tunnels.
  • Virtual Network: The gateway must be deployed into the VNet that contains the GatewaySubnet.
  • Public IP: The VPN Gateway requires a public IP address for receiving connections from the internet.
  • ExpressRoute/Private scenarios: For private connectivity you may use ExpressRoute or combine ExpressRoute + VPN; most S2S/P2S tunnels will use the public internet.
  • Provisioning time: Expect up to ~45 minutes for provisioning — do not cancel or repeatedly redeploy during this time.
Helpful SKU and feature summary:
OptionWhen to chooseNotes
Route-based VPNMost scenarios, dynamic routing, BGP, Azure Route ServerRecommended for flexibility and BGP support
Policy-based VPNLegacy static routing scenariosLimited; fewer features and scalability
VpnGw1 / VpnGw2 / VpnGw3Increasing performance and tunnel capacityChoose based on throughput and tunnel count needs
A presentation slide titled "Creating VPN Gateway" listing key points (VPN Type, SKU Impact, VNet Association, Public IP Requirement) on the left. On the right is a screenshot of the Azure portal showing the "Create virtual network gateway" configuration form.
Provisioning note:
Deploying a VPN Gateway can take up to 45 minutes. This is expected — do not retry or redeploy while the gateway is provisioning.

​
After the gateway is deployed

You can create:
  • Site-to-site (S2S) connections to on-premises devices — requires a Local Network Gateway resource in Azure.
  • Point-to-site (P2S) connections for individual clients — requires client configuration and certificate or other authentication methods.
Common post-deployment tasks:
  • Configure Local Network Gateway(s) and connections (S2S).
  • Configure P2S authentication and client profiles (certificates or Azure AD authentication).
  • Use the gateway in hub-and-spoke topologies by peering VNets and enabling gateway transit.
A screenshot of the Microsoft Azure portal on the "Create virtual network gateway" Review + create page showing "Validation passed" and a list of gateway configuration details (subscription, resource group, name, region, SKU, subnet, VPN type, public IP, etc.).

​
Demo context — Deploying a P2S gateway via the portal

The following demo deploys a VPN Gateway intended for Point-to-Site (P2S) use. The environment already contains:
  • A resource group.
  • A hub VNet and a spoke VNet.
  • A test VM in the spoke to validate connectivity through the hub gateway using gateway transit.
The PowerShell script below shows the variables used to create the hub, spoke, and VM for the lab. 
# ------------------------------- Variables -------------------------------
$resourceGroup      = "rg-az700-p2s"
$locationHub        = "eastus"
$locationSpoke      = "eastus"    # Keep same region for simplicity

# Hub VNet
$hubVnetName        = "vnet-az700-p2s-hub"
$hubAddressSpace    = "10.90.0.0/24"    # Single /24 as requested (no subnets yet)

# Spoke VNet
$spokeVnetName      = "vnet-az700-p2s-spoke"
$spokeAddressSpace  = "10.91.0.0/16"
$spokeSubnetName    = "snet-az700-p2s-spoke-app"
$spokeSubnetPrefix  = "10.91.1.0/24"

# VM in Spoke (private only)
$vmName             = "vm-az700-p2s-spoke-app-01"
$nicName            = "nic-az700-p2s-spoke-app-01"
$nsgName            = "nsg-az700-p2s-spoke-app"

$username           = "kodekloud"
$passwordPlain      = "@adminP@55w0rd"
$securePassword     = ConvertTo-SecureString $passwordPlain -AsPlainText -Force
$credential         = New-Object System.Management.Automation.PSCredential($username, $securePassword)
What the script prepares:
  • Hub VNet (vnet-az700-p2s-hub) — where the gateway will be deployed.
  • Spoke VNet (vnet-az700-p2s-spoke) — with a subnet and a VM for testing.
  • The demo then peers the VNets and enables gateway transit so the spoke VM can route to on-premises via the hub gateway (once the gateway and connections are configured).

​
Portal deployment steps (summary)

  1. Search for “Virtual network gateways” and click Create.
  2. Select your subscription and resource group.
  3. Enter a name (e.g., VPNGateway-AC700) and select the region (e.g., East US).
  4. Gateway type: VPN.
  5. SKU: select an appropriate SKU (e.g., VpnGw1 for lab/testing).
  6. Virtual Network: select the hub VNet containing GatewaySubnet.
    • If GatewaySubnet doesn’t exist, create it from the VNet → Subnets blade. When you choose subnet purpose “Virtual network gateway” the name defaults to GatewaySubnet. Use at least /27.
  7. Public IP address: create a new public IP (for example, vpnGatewayPIP).
  8. Configure Active-Active, BGP, Key Vault access, etc., only if required. For a minimal lab, leave defaults (Active-Active off, BGP off).
  9. Review and Create. Wait for the deployment to complete (up to ~45 minutes).
When validation passes, the portal will show a “Validation passed” screen prior to creating the gateway.
A screenshot of the Microsoft Azure portal showing the "rg-az700-p2s" resource group Overview page with a list of resources (storage account, network interface, VM, public IP, virtual networks, etc.), their types, and locations (all East US). The left navigation menu and top action bar (Create, Delete resource group, Refresh, Export) are also visible.

​
After provisioning completes

  • Create Site-to-Site connections: Add a Local Network Gateway resource to represent on-premises address spaces, then create a connection to the VPN Gateway.
  • Configure Point-to-Site: Upload or configure certificate/authentication and generate client profiles for users to connect to Azure resources.
  • Use with hub-and-spoke: Peer VNets and enable gateway transit so spokes can route to on-premises through the hub gateway.
That completes the deployment portion. Next steps depend on your choice (P2S or S2S) and authentication/route requirements. Use the links above for deeper configuration details and platform limitations.

Watch Video