Almost every company today lives in two places at once: its own buildings and the cloud. The challenge is making those two places feel like one network without exposing anything to the open internet.

The hybrid reality

When a company first moves to the cloud, it rarely moves everything at once. Some servers, databases, and printers stay in the office or in a data centre the company owns. New applications start in the cloud. This mixture is called a hybrid setup, and it is the normal state of most organisations for years. In a hybrid setup, programs on one side need to talk to programs on the other side all day long: a cloud application reads a customer record from an office database, or an office computer opens a file from a cloud server.

Those conversations contain private information such as customer details, financial figures, and passwords. If they travelled across the internet unprotected, anyone along the route could read or alter them. At the same time, the cloud servers should not be reachable by random strangers. The goal is a private path: reachable only by the right people and machines, protected from eavesdropping.

Two main ways to connect

There are two broad approaches to linking a company network to the cloud. The first is a dedicated private line: a physical circuit rented from a telecommunications provider that never touches the public internet. It is fast and predictable, but it is expensive and takes weeks to arrange. In Azure, this is called ExpressRoute. The second approach is a VPN over the internet: ordinary internet connections, with encryption layered on top. It is cheap, it can be set up in under an hour once you know the steps, and it works from anywhere there is internet. In Azure, this is VPN Gateway.

Who needs this

An illustrative example

Picture a hypothetical regional bank with a head office, twelve small branches, and a new customer-service application in Azure. Every branch connects to Azure over a VPN tunnel through its normal internet connection. The head office connects with two tunnels for safety. Remote call-centre staff connect from home with a client program on their laptops. All of the traffic is encrypted, the Azure servers have no public addresses, and the bank’s security team can show auditors exactly who can reach what. That whole picture is built with one family of Azure services, and this guide shows how.

A handful of simple networking ideas unlock everything that follows. Read this chapter slowly and the rest of the guide will feel easy.

IP addresses and networks

Every device on a network has an IP address, a number like 10.1.2.3 that works like a street address for data. Addresses are grouped into networks, and each network is written as a range using CIDR notation, which looks like 10.1.0.0/16. The number after the slash says how many of the leading bits are fixed, which in turn tells you how large the range is. A /16 holds about 65,000 addresses, a /24 holds 256, and a /27 holds 32. Smaller networks carved from a bigger one are called subnets.

Some address ranges, such as 10.0.0.0 to 10.255.255.255, 172.16.0.0 to 172.31.255.255, and 192.168.0.0 to 192.168.255.255, are private: they are reserved for use inside organisations and are not routed on the public internet. Almost every office network and every Azure virtual network uses private addresses.

Why overlapping addresses are a disaster

If your office uses the range 10.1.0.0/16 and your cloud network also uses 10.1.0.0/16, a computer asked to send data to 10.1.5.5 cannot tell whether that machine is down the hall or in the cloud. The two networks overlap, and a VPN cannot join them properly. Planning address ranges so they never overlap, across every office, cloud network, and remote user pool, is the single most important design step. It is also the one most often forgotten.

Routing: following the signposts

Routing is the process of deciding which way to send data so it reaches its destination. A route is a simple rule: “for destinations in this range, send the data that way.” Devices called routers keep tables of these rules. Routes can be written by hand, which is called static routing, or learned automatically from neighbours using a routing protocol, which is called dynamic routing. The most common dynamic protocol between networks is the Border Gateway Protocol (BGP).

NAT: sharing one public address

Network Address Translation (NAT) lets many devices with private addresses share one public address when talking to the internet. A NAT device rewrites the sender address on the way out and remembers how to reverse it on the way back. NAT matters for VPNs because a VPN device behind a NAT must use a special technique, called NAT traversal, to build its tunnel.

Encryption and keys

Encryption scrambles data so that only someone with the right key can unscramble it. Two styles exist. With a shared key (symmetric encryption) both sides use the same secret, which is fast but requires safely sharing the secret first. With public-key (asymmetric) methods, each side has a public part anyone can see and a private part kept secret, which solves the sharing problem but is slower. Real systems, including VPNs, use public-key methods to agree on a fresh shared key, and then use that fast shared key for the bulk of the data.

Tunnels and encapsulation

A tunnel is a logical path between two points through another network. To build one, a VPN uses encapsulation: it takes a whole original data packet, encrypts it, and places it inside a new outer packet addressed between the two tunnel ends. The internet routers see only the outer packet, addressed from one VPN device to the other. They cannot see the inner addresses or the contents.

IPsec and IKE

IPsec is the standard collection of rules for encrypting and authenticating network traffic at the IP level. Inside it, a protocol called ESP (Encapsulating Security Payload) does the actual encryption of the data. A companion protocol, IKE (Internet Key Exchange), is the negotiator: it lets two devices prove their identities, agree on algorithms, and create the shared keys. IKE runs over UDP port 500, and when a NAT device is in the path it switches to UDP port 4500. Azure VPN Gateway supports IKE version 2 for site connections, and also version 1 for some situations.

Ports and firewalls

A port is a numbered door on a device, such as 443 for secure web traffic. A firewall is a guard that decides which doors are open to which visitors. For VPNs, firewalls on the path must allow the VPN’s own traffic, such as UDP 500, UDP 4500, and ESP, or the tunnel will never form. This simple fact explains a large share of “my VPN won’t connect” problems.

With the basics in hand, we can define the service, see its three kinds of connections, and compare it with its closest relatives.

The short definition

Azure VPN Gateway is a managed service that sends encrypted traffic between an Azure virtual network and another location over the public internet, or between Azure virtual networks over Microsoft’s backbone. “Managed” means Microsoft runs the underlying machines, patches them, and keeps two of them ready for you, so you configure behaviour instead of maintaining servers. A virtual network is your own private network in Azure, and the VPN gateway is the single locked door that leads into and out of it for tunnel traffic.

The three connection types

These can be combined on the same gateway. One gateway can carry several site-to-site tunnels for branch offices, many point-to-site connections for remote staff, and a couple of VNet-to-VNet links, up to the limits of the chosen size.

Route-based and policy-based gateways

VPN gateways come in two flavours. A route-based gateway decides what goes into the tunnel by looking at its routing table, treating the tunnel like any other network link. This is flexible, supports dynamic routing with BGP, many tunnels at once, and every connection type, and it is the standard choice today. A policy-based gateway decides by fixed rules that list exactly which address ranges may use the tunnel. It is older, limited to a single tunnel and few features, and survives mainly for compatibility with some old devices. Unless a specific device forces your hand, choose route-based.

Gateway sizes

You choose a SKU, which is simply a size or edition, for the gateway. A larger SKU gives more throughput and allows more tunnels and connections. Current production SKUs are named VpnGw1 through VpnGw5, and versions with “AZ” in the name spread their instances across availability zones for extra resilience. Older sizes, including a Basic SKU, still appear in documents but are not recommended for new work because they lack important features, so check the current documentation for their status and retirement dates. Gateways also come in generations, where generation 2 offers higher performance at several sizes.

VPN Gateway versus its neighbours

People often confuse VPN Gateway with other Azure networking services. ExpressRoute is the dedicated private line mentioned earlier. VNet peering links two Azure virtual networks directly with no gateway at all, and is usually the better choice between two Azure networks. Azure Virtual WAN is a larger managed service that can host many VPN connections and spread them across a global hub. Azure Bastion offers browser-based remote access to virtual machines without a VPN. Chapter 14 compares all of these in detail.

A VPN gateway deployment is made of a few named pieces. Learn what each one is and how they fit together, and every portal screen becomes readable.

flowchart LR
  ONPREM["On-premises network"] --> DEV["On-premises VPN device"]
  DEV --> INET["Public internet with encrypted tunnel"]
  INET --> PIP["Gateway public IP address"]
  PIP --> VGW["Azure VPN Gateway"]
  VGW --> GS["GatewaySubnet"]
  GS --> VNET["Azure virtual network and its subnets"]
  LNG["Local network gateway"] -.-> VGW
  CONN["Connection with shared key and policy"] -.-> VGW

The virtual network and the gateway subnet

Everything starts with an Azure virtual network, divided into subnets. A VPN gateway needs a special subnet that must be named exactly GatewaySubnet. Azure places the gateway’s instances in this subnet and gives each one a private address from it. The subnet is reserved for the gateway alone: you must not put virtual machines or other services in it, and you should not attach a network security group to it, since that can break the gateway. Microsoft recommends a size of /27 or larger so that there are enough addresses for growth, extra features, and coexistence with other gateway types.

The virtual network gateway

The virtual network gateway is the resource you actually create and pay for. Behind it, Azure runs at least two virtual machine instances, normally one active and one on standby, in the gateway subnet. You choose its type (VPN), its VPN type (route-based), its SKU, whether it is active-active, and whether BGP is on. Creating one is not instant: provisioning can take thirty minutes or more, which is why you should create it early in a project.

The public IP address

The gateway needs a public IP address so that the other end of a tunnel can find it on the internet. This is the address your on-premises device is configured to dial. Use the Standard type of public IP, since older types are being retired, and note that the address is tied to the gateway for its life, so plan DNS and firewall rules around it.

The local network gateway

Azure also needs a description of the other side. A local network gateway is a small resource that records the other end’s public IP address (or name) and the address ranges that live behind it. Despite its name, it is not a device. It is an entry in Azure’s address book that says “the office is at this public address and owns these private ranges.” If BGP is used, it also records the peer’s BGP address and number.

The connection

A connection ties the pieces together. It joins the virtual network gateway to a local network gateway (or to another virtual network gateway), names the connection type, and holds the pre-shared key, a secret string that both sides must know to prove they are authorised. It can also carry a custom IPsec and IKE policy, settings for BGP, and options such as connection mode.

The on-premises VPN device

On the other end, a physical or virtual VPN device, such as a firewall or router, must be configured to match. Many vendors’ devices are known to work, and Microsoft publishes configuration guidance for common ones. The device needs a public address of its own, the same pre-shared key, matching encryption settings, and the right local and remote address ranges. A mismatch in any of these prevents the tunnel from forming.

Point-to-site extras

For point-to-site connections, the gateway also holds a client address pool, a private range from which connecting laptops receive addresses, the chosen tunnel type and authentication method, and, for certificate authentication, the root certificate used to validate client certificates. Chapter 8 covers these in detail.

Now we look under the bonnet. How do two devices that have never met build a secure tunnel, and what happens to a single packet that crosses it?

sequenceDiagram
  participant D as On-premises device
  participant G as Azure VPN Gateway
  D->>G: IKE_SA_INIT with proposals and key exchange
  G-->>D: Chosen algorithms and key exchange reply
  D->>G: IKE_AUTH with identity and proof of shared key
  G-->>D: Authentication accepted and child SA agreed
  D->>G: Encrypted ESP packets with real traffic
  G-->>D: Encrypted ESP packets with replies
  D->>G: Periodic keepalive and rekey messages

Phase one: building a safe conversation channel

Before any real data flows, the two devices must talk to each other safely, even though the internet in between is hostile. In the first stage, one side proposes a list of acceptable encryption algorithms, hashing methods, and key-exchange groups. The other side picks one that it also supports. They then perform a mathematical key exchange, called Diffie-Hellman, which lets two parties create a shared secret over an open line without ever sending the secret itself. Anyone watching sees only numbers that are useless without private values never transmitted.

Authentication: proving who you are

Agreeing on keys is not enough, since you might be talking to an impostor. In the authentication step, each side proves it knows the pre-shared key (or presents a valid certificate where supported) in a way that does not reveal the key itself. If the key on one side is different by even one character, authentication fails and the tunnel never forms. This is the most common beginner error, and the cause is almost always a typo or a hidden trailing space.

Phase two: creating the data channels

Once the first channel is safe, the devices use it to negotiate the actual child security associations, the settings and keys for the data tunnel. They agree on which address ranges are allowed through (called traffic selectors), which ESP encryption and integrity algorithms to use, and how long the keys last. Traffic then flows inside ESP packets. Keys are replaced regularly in a process called rekeying, so that even if an attacker somehow captured a key, it would only unlock a small slice of traffic.

The life of one packet

The hidden cost of wrapping: MTU

Every network link has a maximum transmission unit (MTU), the largest packet it will carry, commonly 1,500 bytes. Wrapping and encrypting add extra bytes of header, so a packet that was exactly full-size before becomes too big afterwards. The network then has to split it into pieces, a process called fragmentation, which slows things down or, where fragments are dropped, makes connections hang. The usual remedy is to lower the maximum segment size (MSS) that TCP connections announce, so that data is cut into smaller chunks from the start. A figure around 1,350 bytes is a commonly suggested starting point, but follow your device vendor’s and Microsoft’s current advice and test.

Keeping the tunnel alive

Tunnels are kept up by keepalive messages and dead peer detection, a mechanism where each side checks that the other still responds and rebuilds the tunnel if not. When your on-premises device is behind a NAT, the devices use UDP port 4500 and send regular small packets so the NAT does not forget the path. When a tunnel drops, either side can start negotiating a new one, and Azure’s connection status changes from Connected to Connecting or Not connected while this happens.

Site-to-site is the most common use of VPN Gateway: joining a whole office or data centre network to Azure. This chapter walks through the stages and the settings that matter.

The big picture of building one

The pre-shared key

The pre-shared key (PSK) is a secret string that must be identical on both ends. Choose a long, random value, at least thirty-two characters, with no easily guessed words. Store it in a proper secret store such as Azure Key Vault, not in a shared document or a chat message. Rotate it on a schedule and whenever someone who knew it leaves the team. Remember that changing it requires updating both ends at nearly the same time, so plan a short maintenance window.

IPsec and IKE policies

The gateway offers sensible default settings and also accepts several proposals when negotiating, which is why many devices connect without special effort. However, many organisations need exact control, for example to meet a compliance requirement or to match a device that supports only certain algorithms. For this, a custom IPsec and IKE policy lets you specify the encryption algorithm, integrity algorithm, Diffie-Hellman group, lifetimes, and perfect forward secrecy setting. When you set a custom policy, the gateway uses only that policy, so the device must match it exactly.

Perfect forward secrecy (PFS) means that each new data key is derived from a fresh key exchange, so the compromise of one key reveals nothing about past or future keys. It is the safer choice and is commonly required by security standards.

Choosing the connection protocol

Connections can use IKE version 2, which is the modern choice, or IKE version 1, which exists for older devices. Check what your device supports and prefer the newest. Where your on-premises device is behind a NAT, the devices automatically use NAT traversal over UDP 4500, but not every device or NAT behaves well, so test it and confirm with the vendor.

On-premises device considerations

• Public address: use a fixed public address if you can. If your provider gives a changing address, the tunnel will break whenever it changes.
• Firewall rules: allow UDP 500, UDP 4500, and the ESP protocol between your device and the Azure gateway’s public address.
• Routes: make sure your office routers send traffic for the Azure ranges to the VPN device.
• Clock and time: keep device clocks synchronised, since some checks and logs depend on accurate time.
• Firmware: update the device. Old firmware often has known VPN bugs and security flaws.
• Supported list: look for the vendor in Microsoft’s list of validated devices, which comes with tested configuration examples.

Connection modes and who starts the tunnel

By default either side can start the tunnel, and whichever needs it first begins the negotiation. Some designs prefer that the on-premises side always initiates, for example when the Azure side must not dial out to a changing address, and the connection can be set to respond-only mode. Whichever you choose, document it, since it affects what you check first when the tunnel is down.

A hypothetical example

A small manufacturer connects its factory to Azure. The factory range is 192.168.10.0/24 and the Azure network is 10.20.0.0/16. The gateway subnet is 10.20.255.0/27. The local network gateway records the factory firewall’s fixed public address and the 192.168.10.0/24 range. A custom policy requires AES-256, SHA-256, a strong DH group, and PFS. The key is a random 40-character value in Key Vault. After the tunnel connects, the team tests a large file copy to confirm there is no MTU problem and then schedules a reminder to rotate the key every year.

A tunnel that is up but has no route is like a road with no signposts. Routing decides who can reach whom, and getting it right is as important as the tunnel itself.

Static routing: write the map by hand

With static routing, you list the address ranges that live behind each side. In Azure, the local network gateway holds the on-premises ranges, and the gateway automatically adds routes for them. On-premises, you configure the device to send the Azure ranges into the tunnel. Static routing is simple and predictable, and it suits small, stable networks. Its weakness is that every change, such as a new subnet at the office, requires someone to edit the list on at least one side, and forgetting means that the new subnet cannot be reached.

BGP: let the networks talk

With BGP, the two sides advertise their address ranges to each other automatically. When a new subnet appears, it is learned within seconds. If one tunnel fails, routes through it are withdrawn and traffic uses another path. Each network has an autonomous system number (ASN), an identifier for its routing domain. Azure VPN gateways use the default private ASN 65515, and you can choose another if it clashes with your own. You give each side a BGP peer address, and the gateway shows learned and advertised routes so you can verify them.

System routes and user-defined routes

Inside the Azure virtual network, traffic follows system routes that Azure creates automatically, including routes learned from the gateway. You can override them with a route table containing user-defined routes (UDRs), for example to force traffic through a firewall appliance. Take care: applying a route table to the gateway subnet is risky and, in many cases, unsupported, because the gateway needs to manage its own routes. Apply route tables to the workload subnets instead.

Hub and spoke with gateway transit

Larger organisations often arrange their Azure networks in a hub and spoke pattern. One central hub virtual network holds shared services, including the VPN gateway. Several spoke networks hold the individual applications, and each spoke is joined to the hub by VNet peering. With a feature called gateway transit, the spokes can share the hub’s VPN gateway instead of each needing its own, which saves money and keeps connectivity in one place.

flowchart LR
  OFFICE["Office network"] --> TUN["VPN tunnel"]
  TUN --> HUBGW["VPN Gateway in hub network"]
  HUBGW --> HUB["Hub virtual network with shared services"]
  HUB --> SP1["Spoke 1: web application"]
  HUB --> SP2["Spoke 2: data platform"]
  HUB --> SP3["Spoke 3: test environment"]
  REMOTE["Remote laptops"] --> HUBGW

To make this work, the peering on the hub side allows gateway transit, and the peering on each spoke side is set to use the remote gateway. After any change in the gateway or peering, spokes may need their peering refreshed, or new routes may not appear. Spokes do not automatically reach each other through the hub unless you add routing for that, usually through a firewall in the hub, because peering is not transitive by default.

Forced tunneling

Some organisations require that all internet-bound traffic from Azure workloads travel back through the company’s on-premises firewall for inspection. This is called forced tunneling. It is done by advertising a default route, meaning “everything else,” toward the tunnel. It satisfies strict policies, but it makes cloud servers’ internet access depend on the VPN link and on-premises device, adds delay, and can break services that must reach Azure platform addresses directly. Use it only when required, and test thoroughly.

Overlapping address ranges and NAT

When two networks overlap and you cannot renumber either, the VPN gateway offers a NAT feature that translates one range to a different, non-overlapping range as traffic crosses the tunnel. It is useful after mergers or when connecting partners who use common ranges. It adds complexity, so treat it as a repair, not a design goal, and read the current documentation for supported scenarios and limits.

Not every connection is an office. Often it is a person with a laptop. Point-to-site gives each device its own secure tunnel into your Azure network.

How it works

A user starts a VPN client program on a laptop. The client contacts the gateway’s public address, proves who the user is, and the gateway gives the laptop an address from a private client address pool you defined. The laptop is then effectively part of the Azure network and can reach the resources the routes and rules allow. When the user disconnects, the address returns to the pool. No hardware at the user’s location is needed, which is why the model is popular for remote work.

Tunnel types

You can enable several types on one gateway so that different devices use what works for them. The practical advice is to start with OpenVPN for the widest compatibility, and add others only where there is a reason.

Authentication methods

• Microsoft Entra ID: users sign in with their normal work account, and your organisation can apply multifactor authentication and conditional access, rules such as “only from managed devices.” This is the strongest and most manageable option and works with OpenVPN and the Azure VPN Client.
• Azure certificate: you upload a root certificate to the gateway, and each user’s device carries a client certificate issued from it. Secure if you manage certificates well, but distribution and revocation take effort.
• RADIUS: the gateway asks an existing authentication server, such as one used for other company services, to approve each login. Useful where such a server already exists.

Split tunnelling and what traffic goes where

By default, a point-to-site client sends only traffic destined for Azure ranges into the tunnel, and everything else goes straight to the internet. This is called split tunnelling, and it keeps the gateway free of video calls and web browsing. If policy requires all traffic to go through the tunnel, a default route can be pushed to clients, at the cost of more load and delay. Remember that when the Azure network’s ranges change, clients may need to download an updated profile to learn the new routes.

Client software and profiles

Microsoft provides the Azure VPN Client for several platforms, and standard OpenVPN clients can also be used with exported profiles. Administrators distribute a configuration profile to each user, often through device management tools. When you change the gateway’s authentication or address settings, you may need to regenerate and re-issue profiles, so plan the rollout.

Good habits for remote access

• Use Entra ID with multifactor authentication and conditional access wherever you can.
• Give users access only to what they need, using network security groups and routing, not the whole network.
• Keep the client address pool separate from every other range, and large enough for peak users.
• Disable access promptly when someone leaves, and review active users regularly.
• Log connections, so you can see who connected, when, and from where.

Sometimes both ends of the connection are in Azure. There are two ways to join them, and choosing the right one saves money and effort.

VNet-to-VNet over VPN

A VNet-to-VNet connection uses a VPN gateway in each of the two virtual networks and an encrypted tunnel between them, much like a site-to-site connection. The networks can be in different regions, different subscriptions, or even different Microsoft Entra tenants. Traffic travels over Microsoft’s backbone network, not the public internet, though it is still encrypted by IPsec.

VNet peering: the simpler cousin

VNet peering joins two virtual networks directly through Microsoft’s backbone, with no gateway and no encryption layer of its own. It is faster, has lower delay, costs less, and has no gateway bandwidth limits. It is the preferred way to connect two Azure virtual networks in the great majority of cases. The main reasons to choose a VPN gateway between networks instead are a requirement for IPsec encryption on the link by policy, a need to connect across boundaries that peering does not support, or the use of existing gateway-based routing designs.

Combining VPN and peering

The two are not enemies. A very common design uses peering between hub and spokes inside Azure, and a VPN gateway in the hub for the connections to offices and remote users, as shown in chapter 7. Gateway transit is what makes the two features cooperate.

Cross-region and cross-subscription planning

When networks sit in different regions, remember that distance adds delay, which cannot be removed: light in fibre travels roughly 200,000 kilometres per second, so a path of 1,000 kilometres adds about five milliseconds each way. Data crossing regions can also cost more than data staying inside one region. When networks sit in different subscriptions, make sure the right people have permissions to create the links on both sides, and agree who owns shared keys and who responds to problems.

A single tunnel on a single device is a single point of failure. Production designs plan for broken devices, broken links, and broken data centres.

Where things can fail

A VPN connection has many parts, and any of them can fail. The Azure gateway instance can be restarted for maintenance. The on-premises device can crash or be rebooted. The office’s internet link can be cut by a digger. An internet provider can have a routing fault. A whole Azure data centre can lose power. The aim of resilience design is that a failure of any one of these causes a brief hiccup, not an outage.

Active-standby: the default

By default, a gateway runs two instances: one active carrying traffic and one standby ready to take over. If the active instance fails, or Azure performs planned maintenance, the standby takes over within a short time, typically seconds to a minute or so, and tunnels reconnect. This protects against Azure-side failures but not against a failure on your own device, and tunnels do drop briefly during switchover.

Active-active: both instances working

In active-active mode, both gateway instances have their own public IP address, and each can hold tunnels at the same time. Your on-premises device can connect to both, so if one instance is restarted, the other keeps carrying traffic without waiting for a switchover. Combined with BGP, traffic can use both tunnels, and the failure of one simply shifts the traffic to the other.

flowchart LR
  DEVA["On-premises device A"] --> T1["Tunnel 1"]
  DEVA --> T2["Tunnel 2"]
  DEVB["On-premises device B"] --> T3["Tunnel 3"]
  DEVB --> T4["Tunnel 4"]
  T1 --> GW1["Gateway instance 1"]
  T3 --> GW1
  T2 --> GW2["Gateway instance 2"]
  T4 --> GW2
  GW1 --> VNET["Azure virtual network"]
  GW2 --> VNET

Zone redundancy

A VPN gateway SKU with “AZ” in its name spreads its instances across availability zones, physically separate data centre buildings within a region, each with independent power and cooling. A zone-redundant gateway survives the loss of an entire zone. For new production deployments, zone-redundant SKUs are the default choice wherever the region supports them, and the extra cost is modest compared with the protection.

Redundancy on your own side

Even the best Azure design fails if your office has a single device and a single internet line. A full design has two VPN devices at the office, possibly through two different internet providers, each connected to the gateway. With an active-active gateway and two devices, you get four tunnels, as shown in the figure. BGP lets the networks reroute automatically if any tunnel fails.

Backing up a private line with a VPN

A common pattern combines ExpressRoute, the dedicated private circuit, with a VPN as the backup. Both can be attached to the same virtual network, and the routing is arranged so that the ExpressRoute path is preferred and the VPN takes over if ExpressRoute fails. This coexistence gives the speed and reliability of a private line with the lower cost and quick setup of a VPN as insurance. It needs careful routing design, so test the failover on purpose before you need it.

Testing failure on purpose

• Reboot one gateway instance during a maintenance window and watch tunnels and application behaviour.
• Disable one on-premises device or tunnel and confirm that traffic moves to the other path.
• Measure how long the switchover takes, and compare it with your applications’ timeouts.
• Write down the results, and repeat the test after any big configuration change.

A VPN that is secure but painfully slow will be abandoned by its users. This chapter explains what limits VPN speed and how to estimate and improve it.

Five limits in a chain

The speed of a VPN link is set by the slowest of several things. The first is the internet connection at each end: a 200 Mbps office line cannot carry a 1 Gbps tunnel. The second is the gateway SKU, which has an aggregate throughput limit. The third is the single tunnel limit, because one tunnel and especially one encrypted flow can carry less than the whole gateway. The fourth is the on-premises device, whose processor must encrypt and decrypt every packet. The fifth is latency, the delay between the two ends, which limits how fast a single connection can ramp up.

Latency and the single-connection limit

Latency is the delay for data to travel from one end to the other and back, called the round-trip time. A single TCP connection can only have a limited amount of unconfirmed data in flight, called its window. If the window is 64 kilobytes and the round-trip time is 20 milliseconds, then at most 64 kilobytes can be delivered every 20 milliseconds, which is about 26 megabits per second, no matter how fast the pipe is. Modern systems scale the window, but the lesson holds: a single file copy over a long-distance VPN may be far slower than the link’s rating, while many parallel connections together can fill the pipe.

Estimating transfer times

As with any link, estimate before you start. Data sizes are in bytes, but link speeds are in bits, and there are eight bits to a byte. A 2 terabyte transfer is about 16,000 gigabits. At a steady 500 megabits per second, that is 32,000 seconds, or about 8.9 hours. Real transfers rarely reach the rated speed, because of encryption overhead, packet headers, and competing traffic, so assume about 70 percent, which makes it close to 12.7 hours.

If a large one-time bulk copy would take weeks, a VPN is the wrong tool for that job. Use a shipped offline device or a dedicated circuit for the bulk load, and keep the VPN for everyday traffic and small changes.

Choosing a gateway size

Start by listing your needs: the peak aggregate traffic across all tunnels, the number of site-to-site tunnels, the number of simultaneous point-to-site users, whether BGP is needed, and whether zone redundancy is required. Pick a SKU whose published limits are comfortably above those needs, with headroom of at least thirty percent, since a gateway running close to its limit adds delay and drops packets. You can resize a gateway within the same family without rebuilding it in many cases, but changes between certain generations or types may require recreation, so check the current documentation before relying on it.

Ways to improve throughput

• Use multiple tunnels and active-active so that traffic spreads across several paths, and use BGP to balance it.
• Tune MSS and MTU so that packets are not fragmented.
• Choose faster encryption modes such as AES-GCM, which processes encryption and integrity together and is often faster on modern hardware.
• Upgrade the on-premises device if its processor is the limit, or enable hardware encryption support.
• Use parallel transfers for bulk data so that many connections share the pipe.
• Put workloads close to users, in the nearest suitable region, to cut latency.
• Move to ExpressRoute when you need predictable, high bandwidth, and low delay beyond what internet VPNs deliver.

Scaling out beyond one gateway

When a single gateway reaches its limit, you have options. You can move to a larger SKU. You can add additional gateways in other virtual networks and split sites among them. For many branches across a wide area, Azure Virtual WAN provides a managed hub-based service built to scale to many sites, which chapter 14 describes. Plan for growth early, because redesigning connectivity after hundreds of sites are live is painful.

A VPN exists to provide security, but a poorly run VPN can create new risks. This chapter shows how to make the tunnel itself strong and how to limit what a tunnel can reach.

Strong cryptography

Choose modern algorithms and avoid outdated ones. For encryption, AES with 256-bit keys or AES-GCM is the standard choice. For integrity, SHA-256 or stronger. Choose strong Diffie-Hellman groups and enable perfect forward secrecy. Avoid old protocols and algorithms with known weaknesses, even if a device offers them as defaults. Where compliance rules define allowed algorithms, apply a custom IPsec and IKE policy that enforces them, and review it whenever standards change.

Protect the secrets

• Pre-shared keys: long, random, unique per connection, stored in Key Vault, and rotated on a schedule.
• Certificates: for point-to-site, protect the root certificate’s private key carefully, and revoke client certificates promptly when a device is lost.
• Configuration files: remove keys before sharing a configuration or putting it in a ticket or repository.
• Administrator access: limit who can read or change gateway and connection settings, using role-based access control.

Authenticate people properly

For point-to-site access, use Microsoft Entra ID with multifactor authentication and conditional access so that a stolen password alone does not open the door. Conditional access can require a compliant, managed device, a trusted location, or low sign-in risk. Where certificates are used, issue them only to managed devices. Make sure leaving employees lose access on the day they leave.

A tunnel is not a free pass

A common and dangerous belief is that anything arriving through the VPN is trusted. This is false. A laptop that connects might be infected. An office network might contain a compromised machine. Treat traffic from the tunnel as untrusted until checked, the idea behind zero trust. Apply controls inside the Azure network as well:

• Network security groups (NSGs) on workload subnets, allowing only the specific ports and sources needed from the VPN ranges.
• Azure Firewall or a similar inspection service in the hub, to filter, log, and inspect traffic between the VPN ranges and workloads.
• Segmentation: give remote users access to only the subnets they need, not everything.
• Private endpoints for platform services, so that databases and storage are reachable only through private addresses.
• Just-in-time and least-privilege administration, so that even a connected user cannot reach management ports without approval.

Protect the gateway’s front door

The gateway’s public IP address is visible on the internet and will be probed. Only the VPN protocols are listening, which keeps the exposed surface small. Enable Azure DDoS Protection on the virtual network if the gateway is a critical entry point, since a flood of junk traffic at the gateway can disrupt every tunnel. On the on-premises side, restrict who can reach the VPN device’s management interface, and keep its software updated.

Log and watch

Turn on diagnostic logs for the gateway, and send them to a central workspace. Alert on tunnel disconnects, repeated failed authentications, unusual connection volumes, and logins from unexpected places. Logs are also your evidence in an audit or incident, so choose a retention period that matches your obligations.

Good VPN design is mostly good network design. Planning addresses and names before you build prevents most pain later.

Plan the address space like a city map

Give every office, data centre, Azure network, and remote user pool its own non-overlapping range, and leave room to grow. A neat approach is to reserve a large block per region or business unit and carve sub-ranges from it. Keep a single, shared record of allocations, such as a simple spreadsheet or an IP address management tool, so that no team accidentally reuses a range. Include the ranges used by point-to-site clients and by Kubernetes clusters, which can consume surprisingly large blocks.

DNS: names, not just numbers

People and programs prefer names to numbers. DNS turns names such as sql.contoso.internal into addresses. In a hybrid setup, names must resolve correctly on both sides: an office computer must resolve the names of Azure servers, and Azure servers must resolve the names of office servers. This often requires DNS forwarding: office DNS servers forward Azure-related questions to Azure, and Azure forwards office-related questions back. Azure offers Azure DNS Private Resolver, a managed service for this, so you do not need to run your own DNS servers in virtual machines.

Private endpoints add a wrinkle. When a storage account or database gets a private endpoint, its name should resolve to a private address in your network. For on-premises users reaching it over the VPN, the office DNS must forward that name to Azure’s private DNS, or users will receive the public address and bypass the private path. Many mysterious “it works from Azure but not from the office” problems are DNS problems in disguise.

Reaching private services over the tunnel

One of the best uses of a VPN is reaching Azure services privately. With a private endpoint, an Azure service such as a storage account gets an address inside your virtual network, and on-premises computers reach it through the tunnel without any public exposure. Combine this with firewall settings on the service that deny public access. The result is a service that exists only on your private network.

Azure Virtual WAN as a design alternative

Azure Virtual WAN is a managed networking service that bundles VPN gateways, ExpressRoute gateways, and routing into a virtual hub. Instead of building and maintaining many gateways and routes yourself, you attach branches and virtual networks to the hub, and Azure handles much of the routing automatically, even between branches. It suits organisations with many sites, and its pricing and limits differ from standalone gateways. For a handful of sites, a normal VPN gateway is simpler and often cheaper; for dozens or hundreds, Virtual WAN is worth evaluating.

Network security groups and the gateway

Do not attach a network security group to the GatewaySubnet. Control access at the workload subnets that traffic reaches after the gateway. For traffic coming from the VPN, remember that source addresses will be the on-premises ranges or the point-to-site pool, so write your rules in those terms. Use service tags and application security groups to keep rules readable as the environment grows.

Common design mistakes

• Choosing a gateway subnet too small, then being unable to add features or a second gateway type.
• Picking a popular default range such as 10.0.0.0/16 or 192.168.1.0/24, which collides with a partner or a home network.
• Forgetting DNS entirely, and then connecting by IP address in a panic.
• Giving every spoke its own gateway when one shared hub gateway would do.
• Leaving the point-to-site pool too small for peak users.

Azure offers several ways to connect networks and people. Picking the right one is a design decision, and each option has a natural home.

flowchart TD
  A["Need to connect to Azure"] --> B{"Who is connecting"}
  B -->|"Two Azure networks"| C["VNet peering"]
  B -->|"An office or data centre"| D{"Need dedicated private bandwidth"}
  B -->|"Individual remote users"| E["Point-to-site VPN"]
  B -->|"Admin to a few VMs only"| F["Azure Bastion"]
  D -->|"Yes, high or predictable"| G["ExpressRoute"]
  D -->|"No, internet is fine"| H{"How many sites"}
  H -->|"A few"| I["Site-to-site VPN Gateway"]
  H -->|"Dozens or more"| J["Azure Virtual WAN"]

The main options

Combining options

These tools are layers, not rivals. A typical enterprise uses ExpressRoute for its main data centre links, VPN Gateway site-to-site tunnels as a backup and for small branches, point-to-site for remote workers, peering inside Azure, Private Link for services, and Bastion for occasional administration. Each does what it does best.

Third-party appliances

Some organisations already run network appliances from other vendors, such as firewalls or software-defined WAN devices, and place them in Azure as virtual machines. These can act as VPN endpoints too, offering vendor-specific features and consistent management with on-premises equipment. The trade-off is that you manage the appliance, its updates, and its resilience yourself, while the managed gateway is run by Azure. Choose appliances when you need a specific feature the managed gateway does not offer.

You cannot fix what you cannot see. Good monitoring tells you a tunnel is struggling before users complain.

What to watch: metrics

Azure Monitor collects numerical metrics about the gateway and its connections. The most useful ones are the following.

What happened: logs

Azure also offers diagnostic logs, which record events as text. Several log categories exist, covering general gateway events, tunnel state changes, route changes, IKE negotiation messages, and point-to-site user connections. The IKE logs are especially valuable, because they show which settings each side proposed and where negotiation failed, such as “no proposal chosen,” which means the two sides share no common algorithm. Send these logs to a Log Analytics workspace so you can search them, keep them for a suitable period, and build alerts on them.

Alerts worth setting

• A tunnel is down or flapping, meaning it repeatedly goes up and down, for more than a few minutes.
• A BGP session is down, or the number of learned routes changes sharply.
• Gateway bandwidth stays above about seventy percent of the SKU limit.
• Packet drops rise above a normal baseline.
• Point-to-site connections approach the SKU maximum.
• Gateway or connection configuration changes, from the activity log, so that you know who changed what.

Network Watcher tools

Azure Network Watcher includes tools useful for VPN work. A VPN troubleshoot check inspects a gateway or connection and reports problems it can detect. Connection troubleshooting tests reachability between a virtual machine and a destination. Next hop and effective route views show where Azure thinks traffic will go. Packet capture on gateways lets you record traffic when you need to see exactly what is crossing the tunnel, at the price of added effort and storage.

Do not forget the other end

The on-premises device has its own logs and counters, often more detailed than Azure’s about why a negotiation failed. Make sure the people who manage it can share them, and set up alerting there too. When both ends log to a central place, you can follow one conversation from both sides.

VPN problems feel mysterious until you learn that they fall into a few families. Work through the layers in order and most faults surrender quickly.

A layered method

Common symptoms and likely causes

The classic top five

1. The pre-shared key differs by a character. Re-enter it on both sides by copy and paste, and watch out for spaces.
2. Overlapping address ranges. Draw both ranges. If they overlap, the fix is renumbering or NAT.
3. A firewall blocks the VPN’s own ports. Allow UDP 500, UDP 4500, and ESP.
4. A policy mismatch. One side insists on an algorithm or group the other does not support.
5. MTU trouble. The tunnel is fine, but big packets disappear.

Resetting and recovery tools

Azure allows you to reset a connection, which forces the tunnel to renegotiate, and to reset the gateway, which restarts its instances. Both cause a brief outage, so use them with care and outside peak hours. Resetting a connection is a gentle first move for a tunnel stuck in a strange state. Resetting the whole gateway is a bigger step for when metrics and logs suggest the gateway itself is unhealthy. Always record what you did and why.

A VPN is not set up once and forgotten. Keys age, devices are replaced, offices open and close, and standards move on. Treating the VPN as a living service keeps it dependable.

flowchart LR
  A["Plan addresses and design"] --> B["Build as code"]
  B --> C["Test in a lab or staging"]
  C --> D["Connect production"]
  D --> E["Monitor and review"]
  E --> F["Change safely"]
  F --> C
  E --> G["Rotate keys and retire old tunnels"]

Plan and document first

Write a short design document before you create anything. It should list all address ranges, the gateway SKU and why you chose it, whether active-active, zone redundancy, and BGP are used, which authentication methods apply, who owns each on-premises device, which keys exist and where they are stored, and how failover is expected to behave. This is the page everybody will reach for during the first incident, and it is far easier to write on a calm day.

Build as code

Infrastructure as code means describing your resources in text files that a tool turns into real resources, using Bicep, ARM templates, or Terraform. A VPN deployment has many linked parts, and code makes it repeatable, reviewable, and recoverable. If a region is lost or a mistake deletes a connection, you can rebuild it from code in minutes, apart from the long gateway provisioning time. Keep secrets such as pre-shared keys out of the code itself: reference them from Key Vault at deployment time.

Test before production

Create a lab connection that mirrors the real design, even with a smaller SKU. Many vendors’ devices have a virtual edition that can run in Azure for testing. Confirm negotiation, routes, BGP, DNS, and large transfers. Test failover by switching off a tunnel and a device. Record how long traffic takes to recover. Apply the same checks to every change before it touches production.

Change safely

Changes to a VPN affect every user of the tunnel, so schedule them in agreed windows and have a way back. Typical risky changes include changing the IPsec policy, replacing a device, changing the pre-shared key, and altering routes. For each, prepare the new configuration on both sides, apply it in a planned order, test immediately, and keep the old configuration at hand to restore if needed. Tell users in advance, since a brief drop can interrupt long file transfers or remote sessions.

Routine chores

• Key rotation: change pre-shared keys on a schedule and when staff change.
• Firmware and updates: keep on-premises devices patched, and read Azure service health notices about gateway maintenance.
• Capacity review: compare peak bandwidth and connection counts against SKU limits each quarter.
• Access review: confirm that remote users and administrators still need their access.
• Failover test: practise it at least yearly.
• Cleanup: remove unused tunnels, old local network gateways, and unused public IP addresses.
• Documentation: update the design note and run book after each change.

Moving off older gateway types

Older gateway SKUs, including the Basic SKU and non-zone-redundant sizes, are being phased out in favour of newer ones, and public IP types are changing as well. Check Microsoft’s current announcements for dates and migration tools. In many cases the safe path is to build a new gateway of the target type beside the old one, connect the same sites to both for a test period, and then switch over with a planned cutover and a rollback plan. Start early, because gateway creation takes time and your on-premises teams need to coordinate.

A design pattern is a proven answer to a recurring problem. An anti-pattern is a tempting approach that keeps causing trouble. Here are the most useful of each for VPN designs.

Patterns worth adopting

Anti-patterns to avoid

More anti-patterns in brief

• A gateway subnet that is too small. No room for upgrades, coexistence with ExpressRoute, or growth.
• A gateway per spoke. Costly and hard to manage when gateway transit would do.
• Judging performance with one speed test. Single flows are limited by latency, not by the gateway.
• Using a VPN for huge one-off data loads. An offline device or private circuit is faster and cheaper.
• Leaving unused tunnels and users. They add risk and clutter and serve no purpose.
• Forgetting DNS. Systems connect by IP address in testing and break in production.

This chapter gathers the habits that separate calm operations from late-night panics, and explains where the money goes so that no bill is a surprise.

Where the cost comes from

A VPN gateway is billed mainly by the hour at a rate set by its SKU, whether or not any traffic is flowing. There are additional charges for the public IP address, for data leaving Azure (data coming in is generally free), and for some connection and tunnel features depending on the setup. Prices vary by region and change over time, so use Azure’s pricing calculator and the current price list for a real estimate.

Habits that pay off

Common mistakes, in plain words

• Creating the gateway late. It takes half an hour or more to provision, which can stall a project.
• Attaching an NSG to the gateway subnet. It can break the gateway in ways that are hard to diagnose.
• Using policy-based gateways by habit. They lack features that route-based gateways offer.
• Forgetting to allow UDP 500, UDP 4500, and ESP. The tunnel then cannot form.
• Ignoring MTU. Small tests pass and real workloads hang.
• Allowing everything from the VPN range. A tunnel is a path, not a permission.
• Not refreshing client profiles. Remote users cannot see new ranges after changes.
• Never testing failover. The first real test then happens during an outage.

The scenarios below are illustrative composites that show how the ideas combine. The organisations are invented and the numbers are chosen to teach, not to describe any real company.

What these scenarios share

In every case, success comes from planning addresses and names first, designing for failure, using identity and least privilege rather than trusting the tunnel, and testing both normal behaviour and failure. Teams that treat the VPN as a living service, with monitoring, run books, and regular reviews, keep it unremarkable, which is the best compliment a network can earn.

Short answers to the questions beginners ask most often.

You began with the problem of linking private networks across a public internet, and you now have a complete map of Azure’s VPN service: what it is, how its tunnels are built and kept alive, how to route, secure, scale, watch, and repair it.

Think of VPN Gateway as an armoured van service with its own customs checkpoint. The van keeps the contents sealed on the public road, the checkpoint checks identity and keys at both ends, and the routes decide which goods go where. You supply the plan, the keys, and the rules, and Azure supplies the checkpoint and the staff. The better your address plan, your secrets, and your rehearsals, the more boring your VPN will be, and boring is exactly what you want from a network.