An Azure VPN Gateway setup is not just a portal task. It is a network design decision that determines how reliably developers, workloads, branch offices, and on-premises systems can communicate across a hybrid environment. A gateway can be deployed quickly, but details such as address planning, route propagation, gateway SKU selection, and authentication choices decide whether it remains easy to operate six months later.
This guide focuses on a common use case: connecting an Azure virtual network to an on-premises network through a site-to-site VPN. The same foundation also supports point-to-site access for remote users and can be extended to more advanced multi-site designs.
Start With the Connectivity Pattern
Azure VPN Gateway encrypts IP traffic between an Azure virtual network and another location over the public internet. It is a practical choice when teams need hybrid connectivity without the cost or lead time of a dedicated private circuit.
For a site-to-site connection, Azure deploys a managed VPN gateway in a virtual network. Your on-premises VPN device establishes an IPsec/IKE tunnel to the gateway’s public IP address. Azure represents the remote network through a Local Network Gateway resource, which contains the on-premises address prefixes, public VPN endpoint, and optional BGP details.
Point-to-site VPN is different. It gives individual users or devices a secure connection into Azure, commonly through Azure certificate authentication, Microsoft Entra ID authentication, or RADIUS. It is useful for administrators and developers, but it should not be treated as a replacement for permanent site-to-site connectivity between networks.
Before creating resources, decide whether your requirement is site-to-site, point-to-site, or both. Also determine whether a VPN is the right transport at all. VPN Gateway works well for encrypted hybrid access, moderate traffic volumes, and distributed sites. If a workload has consistently high bandwidth requirements, strict latency expectations, or a need for private connectivity that does not traverse the internet, Azure ExpressRoute may be the better architectural fit.
Plan the Network Before the Azure VPN Gateway Setup
The most expensive VPN problems are often address and routing problems. Start by documenting every network that must communicate: Azure virtual network subnets, office networks, data center ranges, branch networks, and any connected virtual networks.
The address spaces on each side must not overlap. If an Azure virtual network uses `10.20.0.0/16` and the on-premises network also advertises `10.20.0.0/16`, neither side can reliably determine where that traffic belongs. This is especially common after acquisitions, lab environments, or teams that independently adopt popular RFC 1918 ranges.
Reserve a dedicated subnet named exactly `GatewaySubnet` in the Azure virtual network. Azure uses this subnet exclusively for gateway instances. Do not place virtual machines, private endpoints, or application resources in it. Size the subnet with future growth in mind. A /27 is often a sensible starting point for many production designs, though the appropriate size depends on the gateway configuration and planned features.
You should also capture these values before deployment:
- The public IP address or fully qualified domain name of the on-premises VPN device.
- The on-premises address prefixes that Azure must reach.
- The shared key or the process for securely exchanging one.
- Whether Border Gateway Protocol (BGP) is required.
- The IKE and IPsec proposals supported by the on-premises device.
BGP is worth considering when routes may change or when multiple paths exist. Static routes are simpler for a small environment with one tunnel and a stable set of prefixes. BGP becomes much more valuable in hub-and-spoke networks, active-active gateway deployments, and organizations connecting several locations. It adds configuration work, but it reduces the ongoing burden of manually maintaining routes.
Create the Core Azure Resources
In the Azure portal, create or select the target virtual network, then add the `GatewaySubnet`. Next, create a public IP address resource for the VPN gateway. Production designs generally use a Standard SKU, static public IP because it aligns with modern Azure networking capabilities and provides a stable endpoint for the tunnel.
Create the Virtual Network Gateway and select these core settings:
Gateway type and VPN type
Choose VPN as the gateway type. For VPN type, choose Route-based unless you have a specific compatibility requirement for policy-based VPN. Route-based gateways use IPsec tunnels and support modern scenarios such as BGP, point-to-site connectivity, multi-site connections, and active-active configurations. Policy-based gateways are primarily for older devices and constrained interoperability cases.
SKU and availability design
The gateway SKU controls performance, connection limits, and supported capabilities. Do not size it solely around current traffic. Consider expected encrypted throughput, the number of tunnels, point-to-site users, and likely growth over the gateway’s lifetime.
For production workloads that need stronger fault tolerance, assess zone-redundant gateway options where they are available in your chosen Azure region. An active-active design can also provide two gateway instances and two tunnels to compatible on-premises equipment. That design improves resilience, but it requires careful BGP and routing configuration. A single active-standby gateway is simpler and often appropriate for smaller environments with a defined recovery tolerance.
Gateway deployment can take considerably longer than typical Azure resource creation. Treat this as planned infrastructure work rather than an on-demand change during an outage.
Define the Remote Site and Connection
Create a Local Network Gateway after the Azure gateway is provisioning. This resource does not deploy hardware. It tells Azure how to reach the remote network.
Enter the public IP address of the on-premises VPN device and add the remote address spaces. Be precise: include only the networks that should be reachable through the tunnel. Broad prefixes can accidentally route traffic for unrelated networks into a VPN connection, creating difficult-to-diagnose failures.
If you are using BGP, configure the remote ASN and BGP peer address. The Azure virtual network gateway also needs its own ASN and BGP settings. Confirm that ASN values do not conflict with existing routing domains in your environment.
Then create a Connection resource between the Virtual Network Gateway and Local Network Gateway. Select site-to-site, enter the shared key, and enable BGP if applicable. The shared key must match the secret configured on the on-premises device. Store it in an approved secret-management system rather than a ticket, chat message, or deployment script.
On the on-premises VPN device, configure the Azure gateway public IP as the remote peer. Configure the local and remote traffic selectors or route-based tunnel settings according to the device vendor’s guidance, then align IKE version, encryption, integrity, Diffie-Hellman group, and IPsec lifetime settings. Azure defaults work with many current devices, but interoperability sometimes requires a custom IPsec/IKE policy. Change policies only when you understand the behavior on both sides, since overly restrictive or mismatched proposals are a common reason tunnels never establish.
Validate More Than the Tunnel Status
A connection status of Connected confirms that the IPsec tunnel is up. It does not prove that applications can reach their dependencies.
Start validation with routes. Check the effective routes on an Azure virtual machine network interface and confirm that on-premises prefixes point to the virtual network gateway. On-premises routers should likewise have routes for the Azure virtual network prefixes. With BGP, verify that expected prefixes are learned and that route filters are not suppressing them.
Then test traffic in both directions using a known port and host, such as HTTPS to an internal service. ICMP can be helpful, but it is often blocked by host firewalls and is not enough to prove application connectivity. Azure Network Security Groups, subnet route tables, host firewalls, and network virtual appliances can all allow a tunnel to appear healthy while blocking useful traffic.
Azure Network Watcher tools, VPN diagnostics, and gateway logs can narrow the investigation. If the tunnel is disconnected, inspect the IKE and IPsec negotiation settings first. If it is connected but traffic fails, inspect route tables, network security rules, and return paths. Asymmetric routing is particularly common when an appliance or firewall sits between application subnets and the gateway.
Operate the Gateway as Production Infrastructure
A VPN gateway should have the same operational discipline as a production load balancer or firewall. Enable diagnostic settings and send relevant gateway logs and metrics to your monitoring platform. Track tunnel status, bytes transferred, tunnel ingress and egress, and configuration changes.
Set alerts for disconnected tunnels, but avoid relying only on connection-state alerts. A tunnel can be connected while a remote application is unavailable. Synthetic checks from Azure to essential on-premises services provide a more useful view of real business connectivity.
Review access control as well. Limit who can modify virtual networks, route tables, gateways, and Local Network Gateways. A small route change can interrupt critical hybrid applications. Infrastructure as code is especially helpful here because it makes network settings reviewable, repeatable, and recoverable.
Finally, test a planned failure scenario. Confirm how traffic behaves when the on-premises device fails, a tunnel renegotiates, or a route is withdrawn. The best time to learn that a failover path is incomplete is during a maintenance window, not when a production dependency is already unreachable.
A well-designed Azure VPN Gateway setup gives hybrid systems a dependable foundation without making network operations mysterious. Start with clean addressing and explicit routing, choose resilience that matches the workload, and validate the application paths that matter. Those decisions turn a working tunnel into connectivity your engineering teams can trust.
