> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Configuring VPN Gateway
> Guide to planning and deploying an Azure VPN gateway, covering GatewaySubnet requirements, gateway creation options, portal steps, and a hub-spoke lab for P2S and S2S testing.
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:
1. Create a dedicated subnet named exactly `GatewaySubnet` inside the virtual network where the gateway will be deployed.
2. Deploy the VPN gateway resource into that virtual network.
3. Configure the connection type you need (site-to-site or point-to-site) and any additional settings such as BGP or active-active mode.
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.
## 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.
## 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):
```powershell theme={null}
# -------------------------------------------------------------------------------
$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):
1. Search for "Virtual network gateways" and click Create.
2. Choose subscription and resource group.
3. Enter gateway name (e.g., `VPN-GW-AZ700`) and region (must match the VNet region).
4. Gateway type: `VPN`.
5. VPN type: `Route-based`.
6. SKU: choose appropriate SKU (e.g., `VpnGw1` for lab/testing).
7. 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.
8. Public IP address: create a new public IP resource.
9. Active-active: enable only if you have matching on-premises dual-IP configuration.
10. BGP: enable if you require route-based dynamic routing.
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
1. Go to the hub virtual network in the portal.
2. Open Subnets -> Add.
3. For the subnet name enter `GatewaySubnet` (or choose Purpose = GatewaySubnet to set the name automatically).
4. Assign an address range (for example a `/27` like `10.90.0.32/27` depending on your addressing).
5. Save the subnet.
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.
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](https://learn.microsoft.com/en-us/azure/route-server/) for integration details.
* Test connectivity from on-premises devices and VPN clients to verify routes and access to Azure workloads.
References:
* [Virtual network gateways overview - Azure](https://learn.microsoft.com/azure/vpn-gateway/vpn-gateway-about-vpngateways)
* [Azure VPN Gateway SKUs](https://learn.microsoft.com/azure/vpn-gateway/vpn-gateway-about-vpngateway#vpn-gateway-skus)
* [Configure point-to-site connections - Azure VPN Gateway](https://learn.microsoft.com/azure/vpn-gateway/point-to-site-about)
This lesson covered the planning and core steps required to deploy an Azure VPN gateway and prepare for S2S/P2S connections.