Configuring VPN Gateway

Welcome. In this lesson you will learn how to plan and deploy an Azure VPN gateway. This guide covers the required subnet, gateway creation options, portal steps, and a small lab script example to build a hub-spoke topology for testing point-to-site (P2S) or site-to-site (S2S) connections. At a high level, the sequence is:

Create a dedicated subnet named exactly GatewaySubnet inside the virtual network where the gateway will be deployed.
Deploy the VPN gateway resource into that virtual network.
Configure the connection type you need (site-to-site or point-to-site) and any additional settings such as BGP or active-active mode.

The image is a flowchart titled "Configuring VPN Gateway" depicting two steps: "Create Gateway Subnet" and "Create VPN Gateway."

Key differences by connection type:

Site-to-site (S2S): Create a Local Network Gateway to represent the on-premises address space and public IP, then create a Connection between the Azure VPN gateway and the Local Network Gateway.
Point-to-site (P2S): Configure client address pools, authentication method (certificate or Azure AD), and VPN client configuration.

Detailed S2S and P2S setup (tunnel parameters, device configuration, and client packages) are outside the scope of this lesson. Treat this guide as the core steps to prepare and create the VPN gateway.

Start with the GatewaySubnet

The VPN gateway must be placed in a subnet named exactly GatewaySubnet. Azure requires this exact name to allocate and configure the gateway resources. Keep this subnet dedicated to the gateway—do not deploy other workloads in it. GatewaySubnet guidelines:

Property	Recommendation
Name	`GatewaySubnet` (exact match)
Size	At least a `/27` (Microsoft recommends this for scaling and multiple gateway instances)
NSG / UDR	Do not apply Network Security Groups (NSGs) or User-Defined Routes (UDRs) to this subnet; Azure manages required rules
Use	Dedicated to the VPN gateway only

Always name the subnet exactly GatewaySubnet. If the name is different, Azure cannot place the gateway and creation will fail.

The image provides instructions for creating a Gateway Subnet for a VPN gateway, highlighting subnet naming, purpose, size, and configuration requirements. It includes a form for adding a subnet with fields for name, address range, and related settings.

Creating the VPN gateway — options and considerations

When you create the VPN gateway resource, choose options based on your topology, throughput, and feature requirements:

Option	Notes / Recommendation
VPN type	Use `Route-based` unless you require legacy `Policy-based` VPNs. Route-based supports dynamic routing (BGP) and modern scenarios.
SKU	Gateway SKUs (e.g., `VpnGw1`, `VpnGw2`, `VpnGw3`, etc.) determine throughput, maximum tunnels, and available features. Choose according to expected load and connection count.
Virtual network	The gateway must be created in the VNet that contains the `GatewaySubnet`.
Public IP	Assign a public IP to the gateway; this is the internet endpoint for S2S tunnels or P2S clients.
BGP	Enable BGP if you need dynamic route exchange between on-premises and Azure.
Active-active	Enable for high-availability scenarios requiring two simultaneous external IP addresses; requires matching on-premises configuration.

Notes:

If you plan to use Azure Route Server, the VPN must be route-based. See Azure Route Server docs for integration details.
SKU selection affects available features (for example, BGP and active-active support vary by SKU). Reference the Azure VPN Gateway SKUs documentation when choosing.

The image is a guide for creating a VPN gateway, detailing aspects such as VPN type, SKU impact, VNet association, and public IP requirements, alongside a virtual network gateway creation form.

Provisioning time and deployment plan

Provisioning a virtual network gateway can take time. Plan accordingly.

Creating a virtual network gateway can take up to 45 minutes. Do not retry or change configuration mid-provisioning—this can cause failures or require cleanup.

Tips:

Start gateway creation during a maintenance window.
Avoid cancelling and recreating mid-deploy; repeated attempts may require support and cleanup.
Monitor the Deployment in the resource group for progress and failure details.

Summary of the core steps

To deploy a VPN gateway:

Plan the hub VNet address space and reserve a GatewaySubnet.
Create GatewaySubnet with at least a /27 prefix and keep it dedicated.
Deploy the VPN gateway into the VNet containing the GatewaySubnet.
Select appropriate VPN type (route-based), SKU, and public IP configuration.
Allow provisioning time; after creation, configure S2S or P2S connections.

Practical lab example (hub-spoke topology with PowerShell)

This example creates a hub VNet (for the VPN gateway), a spoke VNet (for workloads), and a test VM in the spoke. The hub will host the gateway and be peered to the spoke to enable gateway transit. Corrected PowerShell snippet (note: use single quotes for plaintext password to avoid variable expansion):

# -------------------------------------------------------------------------------
$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 = "subnet-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$5w0rd'
$securePassword = ConvertTo-SecureString $passwordPlain -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential($username, $securePassword)

What this script does:

Creates resource group, hub and spoke VNets.
Creates a VM in the spoke (private-only).
The intended next steps (not shown) would be: create GatewaySubnet in the hub, deploy the VPN gateway into the hub, peer the hub and spoke VNets, and enable gateway transit so the spoke VM can route traffic via the hub gateway (for P2S or S2S testing).

Creating a VPN gateway from the Azure portal

Steps (concise):

Search for “Virtual network gateways” and click Create.
Choose subscription and resource group.
Enter gateway name (e.g., VPN-GW-AZ700) and region (must match the VNet region).
Gateway type: VPN.
VPN type: Route-based.
SKU: choose appropriate SKU (e.g., VpnGw1 for lab/testing).
Virtual network: select the hub VNet that contains GatewaySubnet. If you haven’t created GatewaySubnet, the portal can propose creating one, but it may allocate a large CIDR—manual creation is preferable.
Public IP address: create a new public IP resource.
Active-active: enable only if you have matching on-premises dual-IP configuration.
BGP: enable if you require route-based dynamic routing.

The image shows a Microsoft Azure portal interface where a user is configuring settings to create a virtual network gateway.

If you did not create the GatewaySubnet manually, the portal can create it for you. To avoid unintentionally large allocations, create the subnet in advance and use a /27 (or larger) so you preserve space for other hub services.

Walkthrough: add GatewaySubnet manually

Go to the hub virtual network in the portal.
Open Subnets -> Add.
For the subnet name enter GatewaySubnet (or choose Purpose = GatewaySubnet to set the name automatically).
Assign an address range (for example a /27 like 10.90.0.32/27 depending on your addressing).
Save the subnet.

The image shows a Microsoft Azure portal interface where a user is adding a new subnet to a virtual network. Various configuration options are displayed, including IP address spaces for both IPv4 and IPv6.

Once GatewaySubnet exists, go back to Virtual Network Gateways -> Create and select the hub VNet. The portal will automatically select GatewaySubnet. Configure the remaining options (public IP, active-active, BGP, key vault for certificate auth if needed) and click Create.

The image shows the "Create virtual network gateway" page on Microsoft Azure, displaying configuration details for a VPN gateway. The validation has passed, and options for basic settings like subscription, region, and gateway type are listed.

After clicking Create the deployment enters the provisioning phase; monitor the resource group deployment. Expect up to ~45 minutes for completion.

Next steps after gateway provisioning

For S2S: create a Local Network Gateway representing the on-premises public IP and address spaces, then create a Connection between the Azure VPN gateway and the Local Network Gateway. Configure on-premises device with matching shared key and tunnel parameters.
For P2S: configure client address pool, authentication (certificates or Azure AD), and generate/download VPN client profiles for end users.
For BGP/Route Server integration: enable route-based VPN, set device and ASN values, and configure BGP peering as needed. Refer to the Azure Route Server documentation for integration details.
Test connectivity from on-premises devices and VPN clients to verify routes and access to Azure workloads.

References:

This lesson covered the planning and core steps required to deploy an Azure VPN gateway and prepare for S2S/P2S connections.

Watch Video

Plan a VPN Gateway

Troubleshoot VPN Gateway

​Start with the GatewaySubnet

​Creating the VPN gateway — options and considerations

​Provisioning time and deployment plan

​Summary of the core steps

​Practical lab example (hub-spoke topology with PowerShell)

​Creating a VPN gateway from the Azure portal

​Walkthrough: add GatewaySubnet manually

​Next steps after gateway provisioning

Watch Video

Start with the GatewaySubnet

Creating the VPN gateway — options and considerations

Provisioning time and deployment plan

Summary of the core steps

Practical lab example (hub-spoke topology with PowerShell)

Creating a VPN gateway from the Azure portal

Walkthrough: add GatewaySubnet manually

Next steps after gateway provisioning