- Plan an Azure VPN Gateway based on traffic, availability, and security requirements.
- Create the required GatewaySubnet correctly.
- Configure gateway resources, local network gateways, and VPN connections.
- Verify tunnel status and troubleshoot common failures.
- Design for high availability and resiliency.
1. Plan the VPN Gateway
Begin by capturing requirements and constraints. Your planning decisions should cover:- Which resources need connectivity (VNets, on‑premises sites, branch offices).
- Expected traffic patterns and peak throughput.
- Maximum concurrent tunnels and connection counts.
- Required features (BGP, ExpressRoute coexistence, policy vs route‑based).
- Fault domain and availability needs (zone redundancy, SLA targets).
- IP addressing plan and whether NAT will be used.
| Topic | Questions to answer |
|---|---|
| Scope | Which VNets and on‑premises prefixes must communicate? |
| Throughput | Expected aggregate bandwidth and per‑tunnel usage? |
| Scale | Number of tunnels and concurrent connections required? |
| Features | Need BGP, VNet peering, or ExpressRoute integration? |
| IP plan | Overlapping address spaces? Will NAT be used? |
| Availability | Do you need active‑active or zone redundant deployment? |
2. Create the GatewaySubnet
Azure requires a dedicated subnet named exactly GatewaySubnet in the VNet where the Virtual Network Gateway will be deployed. Size the subnet per the gateway SKU—/27 is a common production starting point, but larger SKUs can require more IP addresses. Do not put other resources in this subnet.GatewaySubnet must be named exactly “GatewaySubnet” and exist in the VNet before deploying a VPN Gateway. Size it according to the gateway SKU (confirm SKU sizing in Azure docs). Avoid placing VMs or unrelated services in this subnet, and be cautious applying NSGs or route tables that could block gateway traffic.
3. Configuration requirements and routing
Key configuration considerations:- Addressing: Ensure Azure and on‑prem prefixes do not overlap unless you implement NAT.
- Routing: Decide between static routes or BGP for dynamic route exchange. BGP is recommended when multiple paths or automatic failover are required.
- Security: Define IPsec/IKE parameters that match your on‑premises device (encryption, integrity algorithms, DH groups).
- Network controls: Avoid NSGs and UDRs on GatewaySubnet that would block required traffic.
Do not let Azure and on‑premises address spaces overlap unless you have a NAT strategy. Overlapping prefixes can prevent proper route propagation and tunnel establishment.
4. Gateway types: route‑based vs policy‑based
Choose the gateway type carefully—this affects interoperability and features:| Gateway type | Use case | Notes |
|---|---|---|
| Route‑based | Modern scenarios (VNet‑to‑VNet, BGP support, multiple S2S connections) | Uses IP routes, recommended for most deployments |
| Policy‑based | Legacy devices requiring static traffic selectors | Limited scalability and no BGP support; use only if required by on‑prem device |
5. Choose the right SKU and generation
Azure gateway SKUs differ by throughput, number of tunnels, supported features (BGP, zone redundancy), and price. Match SKU to:- Expected throughput and concurrent tunnels.
- Required features (BGP, ExpressRoute coexistence).
- Availability requirements (zone redundant SKUs for higher resiliency).
6. Create a Local Network Gateway (represents on‑premises)
A Local Network Gateway resource stores your on‑premises public IP and the prefixes that should be routed over the VPN tunnel. These prefixes inform Azure what traffic to send to the on‑premises device. Example: Create a Local Network Gateway with Azure CLI7. Configure the on‑premises VPN device
Configure the on‑prem device to match the Azure gateway settings:- Public IP and identifiers.
- IPsec/IKE parameters: encryption, integrity, DH group, lifetime.
- Shared keys (pre‑shared key must match).
- Routing (static routes or BGP ASN and neighbor details).
8. Create the VPN connection in Azure
Create the connection resource that links the Virtual Network Gateway to the Local Network Gateway (or another Virtual Network Gateway for VNet‑to‑VNet). Specify:- Shared key (PSK).
- IKE version (IKEv1 or IKEv2).
- IPsec/IKE settings (if customizing).
- Enable BGP if using dynamic routing.
9. Verify and monitor the VPN connection
After deployment, validate tunnel establishment and health: Tools and places to check- Azure Portal: Connection blade on the VPN gateway shows tunnel status.
- Network Watcher: Connection troubleshooters and topology view.
- Gateway diagnostics and logs: Enable diagnostics and send logs to a Log Analytics workspace.
- Metrics: Monitor throughput, tunnel up/down, and packet drops.
- Confirm tunnel status = “Connected”.
- Verify BGP sessions (if applicable) and learned routes.
- Validate that traffic flows correctly using packet capture or test VMs.
- Compare IPsec/IKE proposals and shared keys if tunnels fail.
10. Troubleshooting checklist
- Mismatched IPsec/IKE proposals or lifetimes.
- Incorrect pre‑shared key.
- Wrong on‑premises public IP configured in Azure Local Network Gateway.
- Overlapping address spaces without NAT.
- NSGs/UDRs on GatewaySubnet blocking traffic.
- BGP ASN or neighbor misconfiguration.
11. High availability and resilience
Design for resiliency based on your SLA targets:- Active‑Active VPN Gateway: Deploy dual active tunnels with BGP for automatic failover.
- Zone‑redundant SKUs: Use zone‑redundant gateways when available to reduce zonal impact.
- Multiple tunnels: Configure redundant tunnels to different on‑prem public IPs or appliances.
- BGP: Use BGP for dynamic failover and route propagation.