What Does Azure VPN Gateway Mean?
This page mentions older exam versions. See the Current Exam Context and Legacy Exam Context sections below for the updated mapping.
On This Page
What do you want to do?
Quick Definition
An Azure VPN Gateway is a service that lets you connect your company’s physical network to Microsoft’s cloud securely over the internet. It works by creating an encrypted tunnel between your on-premises VPN device and the Azure gateway. Think of it as a secure virtual bridge that keeps your data safe as it travels between your office and the cloud. You can also use it to connect multiple Azure regions together or to connect remote users via Point-to-Site VPN.
Common Commands & Configuration
az network vnet-gateway create --name MyGateway --resource-group MyRG --location eastus --vnet MyVNet --public-ip-address MyPIP --gateway-type Vpn --vpn-type RouteBased --sku VpnGw1Creates a route-based VPN gateway in a specific virtual network with a public IP and SKU.
Tests understanding of --gateway-type Vpn vs ExpressRoute and --vpn-type RouteBased vs PolicyBased, and SKU options.
az network local-network-gateway create --name MyLocalGateway --resource-group MyRG --location eastus --gateway-ip-address 203.0.113.5 --address-prefixes 10.0.0.0/16Creates a local network gateway representing the on-premises VPN device and its address space.
Tests knowledge of local network gateway as definition of on-premises network for S2S connections.
az network vpn-connection create --name MyS2SConnection --resource-group MyRG --vnet-gateway1 MyGateway --local-gateway2 MyLocalGateway --shared-key abc123Establishes a site-to-site VPN connection using a shared key.
Exams test shared-key authentication and the need for matching keys on both ends.
az network vpn-connection list --resource-group MyRG --output tableLists all VPN connections in the resource group in table format for quick verification.
Used in scenarios to verify connection status or number of tunnels.
Set-AzVirtualNetworkGateway -Name MyGateway -ResourceGroupName MyRG -GatewaySku VpnGw3PowerShell command to resize an existing VPN gateway to a higher SKU for more throughput.
Tests awareness that SKU can be changed without recreating, but with downtime.
az network vpn-connection show --name MyS2SConnection --resource-group MyRG --query 'connectionStatus'Queries the connection status of a specific VPN connection to check if it's Connected.
Exams test that connectionStatus field indicates operational state (Connected/NotConnected).
az network vpn-connection ipsec-policy add --connection-name MyS2SConnection --resource-group MyRG --ike-encryption AES256 --ike-integrity SHA256 --dh-group DHGroup14 --pfs-group PFS24 --sa-lifetime 28800 --sa-data-size 102400000Applies a custom IPsec/IKE policy to an existing VPN connection.
Exams test that custom policies override defaults and that parameters like DHGroup and PFS must match on-prem.
Azure VPN Gateway appears directly in 12exam-style practice questions in Courseiva's question bank — one of the most-tested concepts on MS-102. Practise them →
Must Know for Exams
Azure VPN Gateway appears heavily in the AZ-104 (Azure Administrator) exam, particularly in the networking section which makes up about 15–20% of the total questions. Objectives such as 'configure and manage virtual networking' and 'configure and manage hybrid connectivity' directly require you to know the steps to create a VPN gateway, configure a local network gateway, and establish a site-to-site connection. You will also see questions on choosing the correct SKU (Basic vs VpnGw1–5) based on throughput and feature requirements.
For the Azure Fundamentals (AZ-900) exam, the focus is broader, you need to recognize that Azure VPN Gateway is a method for hybrid connectivity and differentiate it from Azure ExpressRoute. Questions are often scenario-based: 'A company needs an encrypted connection over the internet, what should they use?' Answer: Azure VPN Gateway. This exam also tests your understanding of the shared responsibility model, the customer configures the on-premises VPN device and the gateway settings, while Microsoft manages the gateway infrastructure uptime.
The SC-900 (Security, Compliance, and Identity Fundamentals) exam touches on Azure VPN Gateway within the context of network security controls. You may see questions about how encryption protects data in transit and how authentication (pre-shared key or certificates) verifies endpoints.
Beyond Microsoft exams, CompTIA Network+ (N10-008) includes objectives on cloud networking concepts and VPN technologies. You should be able to explain the difference between site-to-site and point-to-site VPNs, as well as the role of IPsec in securing cloud connections. Similarly, the CCNA (200-301) covers IPsec and VPN technologies; questions may ask you to compare traditional WAN connectivity with cloud VPN services.
In the CompTIA Security+ (SY0-601) exam, Azure VPN Gateway appears in the context of securing remote access and site-to-site communication. You might get a question about a penetration testing scenario where the VPN tunnel is a potential attack vector, and you need to recommend best practices like using strong encryption (AES256) and certificate-based authentication.
For the ISC² CISSP exam, VPN Gateway falls under Domain 4 (Communication and Network Security). You should understand how IPsec works at the protocol level, the difference between tunnel mode and transport mode, the role of IKEv2, and how the gateway uses BGP for dynamic routing. Questions could present a case where a VPN tunnel fails to establish, and you must identify whether the issue is with firewall rules, NAT traversal, or misconfigured pre-shared keys.
In all these exams, common question types include: drag-and-drop to order the steps to create a site-to-site VPN, multiple-choice to select the correct SKU based on a bandwidth requirement, and performance-based tasks where you must interpret a network diagram and decide where to place the GatewaySubnet. Being able to read a routing table or analyze a failed connection log is also tested at the advanced levels.
A recurring trap in exams is the confusion between Azure VPN Gateway and Azure ExpressRoute. Many learners choose ExpressRoute for small encrypted connections, but ExpressRoute is a private dedicated line that does not use the internet and is more expensive. The correct answer is almost always VPN Gateway when the question says 'over the internet' or 'encrypted tunnel'. Another trap is forgetting that the Basic SKU does not support BGP or active-active mode, if the question requires BGP for dynamic routing, you must choose VpnGw1 or higher.
Simple Meaning
Imagine your office building is a fortress, with all your important files and computers protected inside. Now, you want to create a secure tunnel from that fortress to a second building in a different city, the Azure cloud, so that people in both places can share documents and run programs as if they were in the same room. Azure VPN Gateway is the technology that builds that tunnel.
On one end of the tunnel, you have your on-premises VPN device, this could be a hardware appliance like a Cisco router or a software VPN server running in your data center. On the other end, you have the Azure VPN Gateway, which is a managed service running in Microsoft’s cloud. The two devices agree on a set of rules for how to encrypt and authenticate the data passing between them.
A common analogy is a secure postal service. You put your data into an envelope (encryption), seal it with a lock (authentication), and send it through a special courier route (the IPsec tunnel) that only the two post offices know. If anyone tries to intercept the envelope, they can’t open it because they don’t have the key.
Azure VPN Gateway supports different types of connections. Site-to-Site (S2S) connects your entire office network to your Azure virtual network. Point-to-Site (P2S) lets individual employees connect from a laptop at home or a coffee shop. VNet-to-VNet connects two different Azure virtual networks directly, like linking two secure rooms within the same cloud building.
Crucially, Azure VPN Gateway is not a simple plug-and-play device. You must configure routing rules, specify which subnets can talk to which, choose the correct SKU based on your bandwidth needs, and ensure your on-premises firewall allows the required UDP ports for IPsec traffic. The gateway itself is deployed in an Azure virtual network, and you typically create a dedicated subnet called the GatewaySubnet.
Behind the scenes, Azure VPN Gateway runs as a pair of active-standby virtual machines managed by Microsoft. If the active instance fails, the standby takes over automatically, so your connection stays up even if hardware breaks. Some higher SKUs support active-active mode, where both instances handle traffic simultaneously for higher throughput.
In short, Azure VPN Gateway is a critical piece of hybrid cloud infrastructure. It gives you the security and compliance of a private connection combined with the flexibility and scalability of the public cloud. For businesses that need to extend their on-premises data center into Azure without buying expensive dedicated circuits, it is the most practical choice.
Full Technical Definition
Azure VPN Gateway is a managed service that acts as a virtual private network (VPN) termination point inside an Azure virtual network. It uses IPsec/IKE (Internet Key Exchange) protocols to create encrypted tunnels over the public internet between Azure and on-premises networks, other Azure VPN gateways, or individual remote clients.
At the core, a VPN Gateway is deployed into a dedicated subnet called the GatewaySubnet, which must be created within the virtual network. The GatewaySubnet must be named exactly that and should have a minimum /27 CIDR range to ensure sufficient IP addresses for the gateway instances and future scaling. The gateway itself is not a single VM but a pair of virtual machines in a high-availability cluster. For most SKUs, one instance is active, the other is standby. If a hardware failure or patching event occurs, failover happens transparently, typically within a few seconds.
Protocol-wise, Azure VPN Gateway supports IKEv1 and IKEv2 for Site-to-Site (S2S) connections, and IKEv2 or SSTP (Secure Socket Tunneling Protocol) for Point-to-Site (P2S) connections. The encryption algorithms available include AES128, AES256, DES, and DES3, along with integrity algorithms like SHA1, SHA256, and SHA384. For perfect forward secrecy (PFS), the gateway supports Diffie-Hellman groups 1, 2, 5, 14, 24, and 2048. In production environments, it is standard practice to use IKEv2 with AES256-GCM for both encryption and integrity, as it provides the best balance of speed and security.
Azure VPN Gateway comes in three main types: Policy-based, Route-based, and ExpressRoute. Policy-based gateways (also called static routing) filter traffic based on source and destination IP address pairs. Route-based gateways (dynamic routing) use BGP (Border Gateway Protocol) to exchange routes and are far more flexible. Route-based is the recommended type for all new deployments because it supports features like active-active mode, BGP, and custom IPsec/IKE policies. ExpressRoute is a separate service but can be combined with VPN Gateway for failover.
Within the Route-based category, there are multiple SKUs: Basic, VpnGw1, VpnGw2, VpnGw3, VpnGw4, and VpnGw5. Each higher SKU supports more concurrent tunnels, higher aggregate throughput (from 100 Mbps for Basic to 10 Gbps for VpnGw5), and more advanced features like active-active mode, BGP, and zone-redundancy. The Basic SKU has significant limitations, it does not support BGP, active-active, or multiple S2S tunnels, and is not recommended for production workloads.
For S2S connections, you must configure a local network gateway resource in Azure, which represents your on-premises VPN device’s public IP and the address ranges it serves. Then you create the VPN connection between the virtual network gateway and the local network gateway. Authentication is done using a pre-shared key, which you define during configuration. For P2S, you typically use certificate-based authentication: the gateway uses a root certificate to sign client certificates, and each client presents that cert to authenticate. Alternatively, Azure Active Directory authentication is available for OpenVPN-based P2S connections.
On the networking side, Azure VPN Gateway relies on UDP ports 500 (ISAKMP) and 4500 (IPsec NAT-T). If your on-premises firewall or NAT device does not correctly handle these ports, the tunnel will not establish. For BGP to work, you must enable BGP on both the gateway and the on-premises device, and the gateway must have a private IP address for BGP peering.
In practice, Azure VPN Gateway is a critical component of a hybrid network architecture. It allows organizations to extend their on-premises Active Directory, file shares, and application servers into Azure securely. It also enables disaster recovery scenarios where a secondary site runs in Azure, ready to take over if the primary on-premises data center goes offline. The gateway can be monitored via Azure Monitor, which provides metrics like tunnel bandwidth, dropped packets, and route count.
One key limitation is that Azure VPN Gateway does not support multicast, broadcast, or arbitrary IP protocols beyond TCP/UDP/ICMP. It also imposes a maximum transmission unit (MTU) of 1400 bytes after the IPsec overhead. If your application requires jumbo frames or multicast, you would need to consider ExpressRoute instead.
Azure VPN Gateway is a robust, highly available VPN endpoint that integrates deeply with the Azure ecosystem. Properly configured, it provides a secure, reliable bridge between your on-premises world and the cloud.
Real-Life Example
Think of a large hospital campus with several buildings, the main hospital, a research lab, and a remote clinic across town. Each building has its own local network with computers, printers, and medical devices. The hospital wants all employees to access patient records and appointment systems as if they were all in the same building, but they don't want to run expensive fiber cables underground. So, they use secure tunnels over the public streets, this is their VPN.
Azure VPN Gateway is like the main security checkpoint at the hospital's main entrance. It has a dedicated guardhouse (the GatewaySubnet) with two security officers (the active and standby gateway instances) that rotate shifts. When a secure courier van (encrypted data packet) arrives from the research lab, the officer checks the driver’s credentials (pre-shared key), inspects the cargo manifest (IPsec policy), and then directs the van to the correct section of the hospital (the Azure virtual network).
Now, the research lab is on the other side of town, that’s your on-premises network. It has its own security checkpoint (your on-premises VPN device, like a Cisco ASA). The two checkpoint officers have agreed on a secret handshake (the pre-shared key) and a set of protocols (IKEv2, AES256) so that they can trust each other. Every time a van travels between them, the cargo is sealed in a tamper-proof container (IPsec encryption) and the containers are numbered sequentially (sequence numbers for replay protection) to ensure no one can capture and resend an old message.
The remote clinic across town has only a small office with a few laptops. Instead of building a permanent tunnel, the hospital gives each doctor a special ID badge and a secure briefcase (the VPN client software). When a doctor opens the briefcase at a coffee shop and sends a message back to the hospital, the main checkpoint recognizes the digital signature on the briefcase (certificate-based Point-to-Site VPN) and lets the doctor access the medical records system remotely.
If the main checkpoint’s guardhouse gets a flat tire, maybe a power failure or a hardware fault, the backup officer instantly takes over, and the courier vans don’t even notice the change. That’s the high-availability failover in Azure VPN Gateway.
In this analogy, everything works because both sides follow the same rules. If the research lab decides to change its secret handshake without telling the hospital, the tunnel breaks. If a doctor’s laptop briefcase gets lost, someone else could try to impersonate them, that’s why certificate revocation lists and strong authentication are critical. Azure VPN Gateway gives the hospital a way to manage all these connections from a central console, monitor traffic volume, and set policies for who can connect, just like a chief security officer would.
Why This Term Matters
In modern IT, almost every organization operates a hybrid infrastructure, some systems on-premises, some in the cloud. Without a secure connection between these environments, data would travel over the public internet unprotected, exposing sensitive customer information, financial records, and intellectual property to interception. Azure VPN Gateway solves this by providing a managed, encrypted tunnel that meets enterprise compliance standards like PCI DSS, HIPAA, and GDPR.
For network engineers and system administrators, the Azure VPN Gateway is often the first piece of cloud infrastructure they configure when migrating workloads. It enables them to test cloud services without fully migrating, they can keep Active Directory on-premises, connect Azure VMs to the same domain, and gradually move applications. This incremental approach reduces risk and maintains business continuity.
Azure VPN Gateway also matters because it integrates with other Azure services. For example, you can route traffic through the gateway to Azure Firewall for inspection, or use it as a backup connection for ExpressRoute. If your dedicated private line goes down, the VPN gateway automatically takes over, keeping your business online. This redundancy is a key requirement for disaster recovery planning.
Cost is another factor. Compared to leasing a dedicated MPLS circuit from a telecom provider, Azure VPN Gateway is much more affordable for small to medium bandwidths. You pay per hour for the gateway instance plus standard egress data transfer rates. For bursty or moderate traffic, this is far cheaper than fixed monthly circuits.
Finally, Azure VPN Gateway is foundational for many certification exams. The AZ-104 (Microsoft Azure Administrator) devotes a significant portion of the networking section to configuring and troubleshooting VPN gateways. The Azure Fundamentals (AZ-900) and Security, Compliance, and Identity (SC-900) exams test your understanding of how Azure VPN provides secure hybrid connectivity. Even non-Microsoft exams like CompTIA Network+ and CCNA expect you to know how cloud VPNs differ from traditional site-to-site VPNs. Mastery of this concept shows employers that you can design and maintain secure hybrid networks.
How It Appears in Exam Questions
Scenario questions are the most common. For example: 'A company has a main office in New York and a remote office in London. They want to connect both offices to Azure over a secure internet connection. The London office has a low-bandwidth link. What type of Azure VPN Gateway should they use?' The answer is a site-to-site VPN with a VpnGw1 SKU, because VpnGw1 supports 250 Mbps aggregate throughput which is sufficient for typical low-bandwidth scenarios.
Another typical scenario involves disaster recovery: 'A company uses Azure as a backup site. They need automatic failover if the primary ExpressRoute link fails. What should they configure?' The answer is an Azure VPN Gateway as a secondary connection (sometimes called a backup VPN) with BGP to announce the same routes. Here, the exam tests your understanding of gateway redundancy and BGP path selection.
Configuration-type questions often ask: 'You need to deploy an Azure VPN Gateway. Which subnet name is mandatory?' The answer is GatewaySubnet, and it must be created before the gateway. Some questions add a twist: 'You are trying to create a VPN gateway, but the deployment fails because the subnet is named 'gateway-subnet', fix it by renaming to GatewaySubnet.'
Troubleshooting questions appear frequently. For instance: 'A site-to-site VPN connection shows as 'Not Connected'. The pre-shared key matches. What is the most likely cause?' Possible answers include firewall blocking UDP ports 500 or 4500, incorrect address spaces on the local network gateway, or a mismatch in IKE versions. You need to know that Azure VPN Gateway defaults to IKEv2, so the on-premises device must also support it unless you disable IKEv2.
On the AZ-104 and Network+ exams, you may be asked to interpret a network diagram. The diagram shows two VNets connected to a VPN gateway, and you need to identify why routing fails. The answer could be that the VNet address spaces overlap, or that the gateway hasn't been configured with BGP route propagation.
Multiple-choice questions around SKUs test your knowledge of limitations: 'Which SKU supports BGP and active-active mode?' The answer is VpnGw1 and above. 'Which SKU does NOT support custom IPsec/IKE policy?' Answer: Basic.
Performance-based labs in the AZ-104 exam may require you to actually create a virtual network, add a GatewaySubnet, deploy a VPN gateway, configure a local network gateway with specific IP ranges, and then create a VPN connection. You must remember to select 'Route-based' rather than 'Policy-based' for BGP support. Some labs also ask you to download the VPN client configuration files for Point-to-Site and validate that clients can connect.
Finally, you might see a question that combines VPN Gateway with Azure Firewall: 'You want all internet-bound traffic from an on-premises network to be inspected by Azure Firewall before going out to the internet. How should you configure routing?' Answer: Enable forced tunneling on the VPN gateway to route traffic to Azure Firewall via a route table that points to your firewall's private IP. This tests your understanding of user-defined routes (UDRs) and how traffic flows through a VPN gateway.
Practise Azure VPN Gateway Questions
Test your understanding with exam-style practice questions.
Example Scenario
Your company has a headquarters in Dallas with 200 employees and a small branch office in Austin with 10 employees. The headquarters has a Cisco ASA 5500 firewall. You want to migrate the company’s internal web application to Azure, but employees in both offices must keep accessing it using their on-premises user accounts (Active Directory domain-joined). Management also requires that all data between offices and Azure is encrypted using AES256 with IKEv2.
First, you log into the Azure portal and create a virtual network named 'AppVNet' with address space 10.0.0.0/16. You then add a subnet named 'AppSubnet' with 10.0.1.0/24 for the web servers, and a separate subnet named 'GatewaySubnet' with 10.0.0.0/27 for the VPN gateway.
Next, you deploy a Route-based VPN gateway with SKU VpnGw2 in the GatewaySubnet, choosing an availability zone for high availability. This takes about 45 minutes. Once deployed, note the gateway's public IP address, for example 13.68.100.50.
Now, create a local network gateway for the Dallas office. You name it 'Dallas-LNG', enter the public IP of the Cisco ASA (e.g., 203.0.113.5), and specify the on-premises address space as 192.168.0.0/16. Repeat for Austin with its smaller range 192.168.50.0/24 and public IP 203.0.113.20.
Create two site-to-site VPN connections, one from the Azure VPN Gateway to Dallas-LNG, the other to Austin-LNG. Set the pre-shared key for each (e.g., 'MyKey123!'). On the Cisco ASA side, configure the VPN tunnel with the same key, destination IP 13.68.100.50, and enable IKEv2 with AES256 and SHA256. Ensure UDP 500 and 4500 are open on the ASA firewall.
Once both tunnels show 'Connected', test connectivity by pinging a VM in the AppSubnet from a Dallas desktop. If ping fails, check that the on-premises firewall allows ICMP, or use a TCP test like PowerShell's Test-NetConnection. Adjust routing, the on-premises routers must have a route pointing to Azure’s 10.0.0.0/16 via the Cisco ASA's internal IP.
Now, employees in both offices can access the web application hosted on 10.0.1.100. Traffic from Austin to Azure goes through the Austin ASA, then the public internet, then the Azure VPN Gateway. The connection is fully encrypted. This scenario demonstrates the exact configuration steps you would perform in a real hybrid environment and is typical of AZ-104 lab tasks.
Common Mistakes
Creating the GatewaySubnet with an insufficient address range, such as /29.
Azure VPN Gateway needs at least a /27 subnet to accommodate the two gateway VMs, future scaling, and additional IP addresses for features like BGP and custom IPsec policies. A /29 only offers 8 IP addresses, which is not enough for the gateway cluster.
Always allocate a /27 or larger subnet for GatewaySubnet, for example 10.0.0.0/27.
Choosing a Policy-based gateway when the scenario requires BGP or active-active mode.
Policy-based gateways (static routing) do not support BGP, active-active mode, or custom IPsec/IKE policies. They also have a limit of 100 tunnels, whereas Route-based gateways can handle thousands. If the exam question mentions BGP, the Policy-based option is a trap.
Select Route-based (dynamic routing) for all new deployments. Use Policy-based only for very specific legacy compatibility or when the question explicitly says 'static routing'.
Forgetting to open UDP ports 500 and 4500 on the on-premises firewall or NAT device.
IPsec IKE uses UDP 500 for key exchange and NAT-T uses UDP 4500 for encapsulation. If these ports are blocked, the VPN tunnel will never establish. This is one of the most common real-world causes of 'Not Connected' status.
Check firewall rules on both the on-premises device and any intermediate NAT devices. Ensure UDP 500 and 4500 are allowed inbound from Azure’s gateway public IP and outbound to Azure’s gateway public IP.
Trying to use the same GatewaySubnet for both the VPN gateway and other VMs or services.
The GatewaySubnet is reserved exclusively for the VPN gateway VMs. Placing any other resources in it will cause the gateway deployment to fail or behave unpredictably. Azure enforces this isolation.
Create the GatewaySubnet with the correct name and range, and do not deploy any VMs, load balancers, or other resources into it. Keep it empty except for the gateway.
Mismatching the IKE versions or encryption algorithms between Azure and the on-premises device.
If the Azure gateway uses IKEv2 but the on-premises device only supports IKEv1, the tunnel will not establish unless you configure a custom IPsec/IKE policy to match. Similarly, using different encryption algorithms (e.g., AES128 vs AES256) causes phase 2 negotiation to fail.
Verify the capabilities of the on-premises device and configure the Azure gateway to match either by selecting the appropriate defaults or creating a custom IPsec/IKE policy under the VPN connection settings.
Selecting the Basic SKU for a production environment expecting BGP or high availability.
The Basic SKU does not support BGP, active-active mode, custom IPsec policies, or multi-site connections. It also has a lower throughput limit (100 Mbps). Deploying it in production means you lose redundancy and flexibility.
Always use VpnGw1 or higher for production workloads. Use Basic only for development or testing without BGP requirements. If the exam question includes BGP, eliminate Basic immediately.
Forgetting to update the on-premises routing table with a route to the Azure virtual network address space.
Even if the VPN tunnel is up, traffic from on-premises to Azure will be dropped if the local router doesn’t know that the Azure address range is reachable via the VPN device. This is a common reason for one-way connectivity, you can ping from Azure to on-premises but not the reverse.
On the on-premises router, add a static route (or a BGP-learned route) pointing the Azure virtual network’s address space (e.g., 10.0.0.0/16) to the internal IP of the VPN device. Then verify propagation.
Exam Trap — Don't Get Fooled
{"trap":"You need to connect two Azure virtual networks in different regions. The question asks whether to use Azure VPN Gateway or Azure VNet Peering. The trap suggests VNet Peering, but the scenario requires encrypted traffic."
,"why_learners_choose_it":"VNet Peering is simpler to configure and costs less (no gateway hourly fee). Learners often default to the simplest option without reading the requirement for encryption. Peering traffic within Azure’s backbone network is encrypted by default at the physical layer, but the question may explicitly state 'ensure traffic is encrypted end-to-end using IPsec', which Peering does not guarantee at the application layer."
,"how_to_avoid_it":"Read the scenario carefully. If the requirement mentions 'IPsec encryption', 'custom encryption policies', or 'encrypted tunnel', choose Azure VPN Gateway with VNet-to-VNet connection. If the question only says 'connect two VNets in different regions' without encryption, VNet Peering is the correct answer.
Also note that VNet Peering supports transitive routing only if you use a hub-spoke topology with a VPN gateway, standalone Peering is non-transitive."
Commonly Confused With
Azure ExpressRoute provides a private, dedicated physical connection from your on-premises network to Azure that bypasses the public internet entirely. Unlike Azure VPN Gateway, ExpressRoute does not use IPsec encryption by default, although you can layer IPsec on top if needed. ExpressRoute offers higher bandwidth, lower latency, and a service-level agreement (SLA) but is significantly more expensive and requires coordination with a telco provider.
If a bank needs a guaranteed 10 Gbps connection with predictable latency for financial transactions, they choose ExpressRoute. If a small business just needs a secure tunnel over the internet for remote access, they use VPN Gateway.
Azure VNet Peering connects two virtual networks within the same Azure region or across regions, using Microsoft’s backbone network. It does not use a VPN gateway and does not encrypt traffic at the IPsec layer (though the underlying Azure network is encrypted physically). Peering is simpler, faster, and cheaper than a VPN gateway for connecting VNets directly, but it does not provide the same level of customizable encryption or support for on-premises connectivity.
You have two application tiers in different VNets, one for frontend and one for backend. You use VNet Peering to let them communicate without a gateway. If you need to connect an on-premises data center to both VNets, you would still need a VPN gateway in the hub VNet.
Point-to-Site (P2S) is a type of VPN connection, not a separate service. It is actually a feature of Azure VPN Gateway that allows individual client computers to connect to Azure. The difference is that a Site-to-Site (S2S) connection joins entire networks, while P2S connects a single device. On the Azure side, both use the same gateway infrastructure, but P2S requires additional client configuration and certificate management.
A salesperson working from a hotel uses a VPN client on their laptop to connect to Azure, that’s P2S. The entire office LAN connecting to Azure is S2S.
Azure Virtual WAN is a larger-scale networking service that can include multiple VPN gateways, ExpressRoute circuits, and software-defined WAN (SD-WAN) integrations in a hub-and-spoke model. While a single Azure VPN Gateway connects one site to Azure, Virtual WAN can scale to hundreds of branches with automated routing and policy management. Virtual WAN is essentially a managed overlay that simplifies large-scale hybrid networking.
A company with 200 branch offices and multiple cloud providers uses Azure Virtual WAN to centrally manage all connections. A company with one or two offices would simply deploy a VPN gateway per region.
There is no separate 'Azure Firewall VPN Gateway'; rather, you can route VPN traffic through Azure Firewall for inspection. Some learners confuse the VPN gateway itself with a firewall service. Azure VPN Gateway only handles encrypted tunnel termination and routing; it does not inspect traffic content. To filter or log traffic from VPN-connected clients, you must place Azure Firewall or a third-party NVA behind the gateway.
You set up a VPN gateway for your sales team. You then create a route table that sends all outbound traffic from the gateway to Azure Firewall for deep packet inspection. The gateway does not do the inspection itself.
Step-by-Step Breakdown
Plan the address space and subnet structure
Before deploying anything, you must decide on the IP address ranges for your Azure virtual network and the GatewaySubnet. The virtual network address space cannot overlap with on-premises networks or other Azure VNets you plan to connect. The GatewaySubnet must have a minimum /27 prefix. This step is critical because overlapping addresses will cause routing failures.
Create the virtual network and GatewaySubnet
In the Azure portal, navigate to 'Virtual networks' and create a new VNet. Add a subnet for your application workloads (e.g., 10.0.1.0/24). Then add a second subnet named exactly 'GatewaySubnet' with the /27 range. The portal will often prompt you to name it correctly. If you use a different name, the gateway creation will fail. This step establishes the container for the gateway VMs.
Deploy the VPN gateway
Select 'Create a resource' and search for 'Virtual network gateway'. Choose your subscription, resource group, and the VNet you created. Select 'Route-based' as the gateway type. Choose the SKU based on your bandwidth and feature needs (e.g., VpnGw2 for 1 Gbps and BGP support). Specify a public IP address or create a new one. Then click 'Review + create'. The deployment takes 30–45 minutes because Azure spins up two virtual machines in the background.
Configure the local network gateway
Create a resource called 'Local network gateway'. This represents your on-premises VPN device. Enter its public IP address and the IP address ranges (prefixes) of your on-premises network. For example, if your office uses 192.168.1.0/24 and 192.168.2.0/24, list both. If you have multiple sites, you need a separate local network gateway for each site. This resource tells Azure where the other end of the tunnel is.
Create the site-to-site VPN connection
Go to your virtual network gateway, select 'Connections', and choose 'Add'. Name the connection, choose 'Site-to-Site (IPsec)'. Select the local network gateway you created. Enter a pre-shared key, a string of at least 16 random characters for security. Optionally, configure custom IPsec/IKE policies. Once created, the status will show 'Connecting' initially, then 'Connected' once both sides negotiate.
Configure the on-premises VPN device
On your local firewall or router, create a VPN tunnel with the Azure gateway’s public IP as the peer. Use the same pre-shared key, IKE version, and encryption settings. Ensure UDP 500 and 4500 are not blocked. If your device supports it, enable BGP to exchange routes dynamically. Many vendors provide configuration scripts from Azure, you can download them from the VPN connection page.
Verify connectivity and test routes
After both sides are configured, the connection status should show 'Connected' in the Azure portal. Test by pinging an Azure VM’s private IP from an on-premises machine, or vice versa. Use tools like PowerShell’s Test-NetConnection or traceroute. Check that BGP routes have been received if you enabled BGP. If connectivity fails, check firewall logs, verify pre-shared keys match, and ensure no address overlaps.
Troubleshooting Clues
Connection stuck in 'Connecting' state
Symptom: The Azure VPN connection shows 'Connecting' for an extended period, never reaching 'Connected'.
Typically caused by mismatched shared keys, incorrect on-premises VPN device configuration, or unreachable on-premises IP.
Exam clue: Exams present a scenario where the shared key is wrong or the on-premises device has incorrect IKE parameters, expecting the admin to check keys and logs.
Intermittent disconnections
Symptom: VPN tunnel drops every few minutes and reconnects automatically.
Often due to dead peer detection (DPD) timeout mismatch, or on-premises device rebooting or running out of idle timeout.
Exam clue: Tests that DPD settings must be consistent and that idle timeouts or firewall rules can cause instability.
BGP routing not working
Symptom: Azure VPN gateway is in active-active mode with BGP enabled, but routes are not exchanged.
BGP peer IPs must be configured correctly on both sides, and the on-premises device must allow BGP port 179.
Exam clue: Exams check that BGP requires a separate IP for each tunnel and that the local network gateway must include the BGP peer IP.
Cannot connect from on-premises to Azure VMs
Symptom: Site-to-site VPN shows 'Connected', but traffic from on-premises cannot reach Azure VMs.
Missing or incorrect network security group (NSG) rules on the gateway subnet or VM subnets blocking inbound traffic.
Exam clue: Tests that even with a working VPN, NSGs can block traffic; exam scenarios often add NSG rules as the culprit.
Policy-based VPN not working with non-standard subnet
Symptom: A policy-based VPN gateway only allows traffic from specific on-premises prefix, not the entire range.
Policy-based gateways require explicit local and remote prefixes; route-based is more flexible for larger networks.
Exam clue: Exams test the limitation of policy-based VPNs and recommend route-based for complex networks.
High latency or packet loss
Symptom: Ping to Azure VMs over VPN shows high latency or packet loss.
Caused by suboptimal routing (e.g., traffic going over the internet instead of direct tunnel), or on-premises bandwidth congestion.
Exam clue: Exams ask about using Azure ExpressRoute for low latency, or checking route tables and BGP best path selection.
VPN gateway provisioning fails
Symptom: Azure portal shows 'Failed' status when creating a VPN gateway.
Common due to insufficient public IP addresses (basic SKU limitation), or subnet size less than /27 for the gateway subnet.
Exam clue: Tests that the gateway subnet must be /27 or larger and that a public IP resource with standard SKU is required.
Point-to-site client cannot connect
Symptom: VPN client shows 'Cannot establish VPN connection' on the client computer.
Root certificate not uploaded to Azure, client certificate expired, or RADIUS server misconfigured if using P2S with RADIUS.
Exam clue: Exams test that the root certificate must be in .cer format and that client certificates must not be expired.
Learn This Topic Fully
This glossary page explains what Azure VPN Gateway means. For a complete lesson with labs and practice, see the topic guide.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Legacy Exam Context
Older materials may mention these exam versions, but learners should use the current objectives for their target exam.
N10-008N10-009(current version)SY0-601SY0-701(current version)Related Glossary Terms
ARM stands for Azure Resource Manager, the management layer that enables you to create, update, and delete resources in your Azure account.
An ARM template is a JSON file that defines the infrastructure and configuration for Azure resources, enabling repeatable and consistent deployments.
Azure App Service is a fully managed platform for building, deploying, and scaling web applications and APIs without managing the underlying infrastructure.
Azure Application Gateway is a cloud-based web traffic load balancer that manages and protects HTTP and HTTPS requests to web applications based on their URL paths and other routing rules.
Azure CLI is a command-line tool that lets you manage Azure resources by typing commands instead of clicking through a web portal.
Azure Cloud Shell is a browser-accessible, authenticated command-line interface for managing Azure resources without needing a local terminal or software installation.
Quick Knowledge Check
1.Which SKU supports active-active mode for Azure VPN Gateway?
2.What is the minimum subnet size required for the GatewaySubnet in an Azure VPN Gateway deployment?
3.A site-to-site VPN connection shows 'Connected', but on-premises hosts cannot reach Azure VMs. What is the most likely cause?
4.Which type of VPN gateway must be used to support dynamically changing on-premises address spaces without reconfigure?
5.When configuring a custom IPsec/IKE policy for a VPN connection, which parameter defines the Diffie-Hellman group for key exchange?