Cloud / Azure VPN Gateway Interview questions

Azure VPN Gateway is a managed virtual network gateway that carries encrypted traffic between an Azure virtual network and another network over the public internet. The other end can be an on-premises site, another VNet, or a single laptop.

Behind the scenes Azure runs two or more gateway VMs inside a dedicated subnet called GatewaySubnet. You can't log into them. Azure patches, replaces and scales them for you.

Site-to-site and VNet-to-VNet links use IPsec/IKE. Point-to-site clients connect with OpenVPN, SSTP or IKEv2. Common uses are branch-office connectivity, remote-worker access to private resources, and encrypted links between regions.

Only one VPN gateway is allowed per virtual network.

There are three connection types, and one gateway can serve all of them at the same time on a route-based SKU.

S2S needs a VPN device on the on-premises side. P2S needs no hardware, only a client. VNet-to-VNet needs a VPN gateway in both virtual networks.

GatewaySubnet is a special subnet that holds the VMs behind a VPN or ExpressRoute gateway. The name must be exactly GatewaySubnet, otherwise Azure won't accept the gateway.

Microsoft recommends a /27 or larger prefix so the subnet has room for active-active instances, ExpressRoute coexistence and future SKU changes.

• Don't deploy VMs or any other resources into it.
• Don't associate an NSG with it. That is unsupported and can break the gateway.
• Avoid a 0.0.0.0/0 user-defined route on it.

If you try to name it anything else, such as VpnSubnet, the portal and CLI will refuse to create a gateway in it. The prefix also can't overlap any other subnet in the same VNet.

A Local Network Gateway (LNG) is an Azure resource that describes your on-premises VPN device. It is not a device itself, just a record Azure uses to know where and how to reach the other side.

It holds the device's public IP address (or FQDN), the on-premises address prefixes that should be routed through the tunnel, and optionally the BGP ASN and peer IP.

You create one LNG per remote site, then link it to the VPN gateway through a connection resource. If the on-premises network changes, you update the prefix list on the LNG, or let BGP do it.

A site-to-site VPN is an IPsec/IKE tunnel between an on-premises VPN device and the Azure VPN gateway. Once the tunnel is up, machines on both sides talk using private IPs as if they were on one routed network.

You need four things:

1. A VPN gateway in the VNet.
2. An on-premises VPN device with a public IPv4 address.
3. A Local Network Gateway describing that device.
4. A connection resource with a matching shared key.

The tunnel is always initiated by one side and stays up as long as traffic or keepalives flow. Traffic crosses the public internet, but it is encrypted.

A point-to-site (P2S) VPN lets one machine connect securely into a VNet without any on-premises VPN device. It suits remote developers, admins and small teams.

You define a client address pool on the gateway, pick a tunnel type and an authentication method, then give users the VPN client profile. Each connected client gets an IP from that pool.

The pool must not overlap with the VNet or any connected on-premises range. After changing peering, DNS or routes, users have to download and import a fresh client profile.

The shared key, also called the pre-shared key (PSK), is the secret both ends use to authenticate each other during IKE negotiation. If the keys differ by even one character, the tunnel never comes up.

Use a long random string. Azure accepts keys up to 128 characters, and the same value must be configured on the on-premises device. Don't reuse it across connections.

Typical symptom of a mismatch: the connection stays Connecting or Not connected, and IKE logs show an authentication failure.

SKUs set tunnel count, throughput and feature support. The families are Basic, VpnGw1-5 and the zone-redundant VpnGw1AZ-5AZ. Figures below are approximate, so check current Microsoft docs before sizing.

Microsoft is steering new deployments toward the AZ SKUs and retiring Basic and non-AZ options, so pick an AZ SKU for anything new.

A VNet-to-VNet connection links two virtual networks through two VPN gateways using an IPsec/IKE tunnel. The connection type in the resource is Vnet2Vnet, and Azure builds the tunnel for you, so no on-premises device or public IP planning is needed on either side beyond the gateways.

It works across regions, subscriptions and even Azure AD tenants. The two address spaces can't overlap.

If you only need private connectivity and not IPsec encryption, VNet peering is usually cheaper and faster. VNet-to-VNet is the pick when you need encryption or already run gateways in both networks.

BGP (Border Gateway Protocol) lets the Azure gateway and your on-premises router exchange routes dynamically instead of relying on static prefix lists. Azure's default ASN is 65515.

You enable it on the gateway, set the ASN and peer IP on the Local Network Gateway, and tick enable-BGP on the connection. Basic SKU doesn't support it.

• New subnets in Azure are advertised to on-premises automatically.
• A failed tunnel's routes are withdrawn, so traffic shifts to a healthy path.
• It enables transit routing between sites and VNets.

Create the gateway subnet, a public IP, then the gateway itself. A Standard static public IP is required for AZ SKUs.

az network vnet subnet create -g rg-net --vnet-name vnet-hub \
  -n GatewaySubnet --address-prefixes 10.0.255.0/27

az network public-ip create -g rg-net -n pip-vpngw \
  --sku Standard --allocation-method Static --zone 1 2 3

az network vnet-gateway create -g rg-net -n vpngw-hub \
  --vnet vnet-hub --public-ip-addresses pip-vpngw \
  --gateway-type Vpn --vpn-type RouteBased \
  --sku VpnGw1AZ --no-wait

Deployment takes roughly 30-45 minutes, hence --no-wait. Afterwards add a Local Network Gateway and a connection.

Before running these, confirm the VNet has free space for a /27 and that the region supports the SKU you pick. The gateway name, SKU and generation are set at creation, and the public IP can't be swapped later without rebuilding. After it finishes, check that provisioningState shows Succeeded, then move on to the Local Network Gateway. For active-active, pass two public IPs instead of one.

Azure supports three options for P2S, and the choice also limits which tunnel type you can use.

Entra ID is the easiest to manage at scale because there are no certificates to distribute or revoke.

P2S supports OpenVPN, SSTP and IKEv2. You can enable more than one on the same gateway.

OpenVPN over 443 is the safest choice when users sit behind restrictive firewalls.

You choose the tunnel type in the P2S configuration, and the client profile you download only contains the protocols you enabled. If users report they can't connect from one location but can from another, test whether the failing network blocks UDP, which is the first thing to rule out for IKEv2.

An active-active gateway runs both gateway instances at the same time, each with its own public IP. Your on-premises device builds a tunnel to each one, so you get two live paths instead of one active and one idle.

It requires a VpnGw1 or higher SKU, two public IPs, and on-premises hardware that can handle two tunnels. BGP is strongly recommended so traffic can use both tunnels (ECMP) and move away from a failed one quickly.

Compared with the default active-standby design, a failure doesn't need a standby to take over, so outages are shorter.

A zone-redundant gateway uses an AZ SKU (VpnGw1AZ to VpnGw5AZ), and Azure places its instances in different availability zones within the region. If one zone fails, the other keeps running.

It needs a Standard static public IP and costs a bit more than the non-AZ version. The SLA is higher too, 99.99% versus 99.95% for the regular VpnGw SKUs.

Zone redundancy protects against a datacenter failure inside a region. It doesn't protect against a full regional outage or a failure of your on-premises device.

Make sure your on-premises firewall lets these through to the gateway's public IP, otherwise the tunnel can't form.

A common mistake is opening UDP 500 but forgetting UDP 4500, which breaks tunnels when a NAT device sits in the path.

The connection resource is the object that links two ends of a tunnel: the Azure virtual network gateway and either a Local Network Gateway (S2S) or another virtual network gateway (VNet-to-VNet).

It's also where tunnel behavior is configured: shared key, connection protocol (IKEv1 or IKEv2), BGP on or off, custom IPsec/IKE policy, DPD timeout, routing weight and connection mode. Without a connection, the gateway and LNG are just two disconnected definitions.

One gateway can have many connections, up to the tunnel limit of its SKU.

The default ASN is 65515. You can change it when you create the gateway, but your on-premises router must use a different ASN or the peers will treat each other as iBGP and behave oddly.

Some numbers are off-limits for your side: Azure reserves 8074, 8075, 12076 and 65517-65520, and IANA-reserved ranges such as 23456 and 64496-64511 can't be used either.

Changing the ASN is only possible while the gateway is being created or through a gateway update, and every connection that uses BGP has to be re-checked afterwards. Write the ASN down in your network design document, because it shows up in the on-premises router's neighbor statement as the remote AS.

Gateway transit lets spoke VNets use the VPN gateway that lives in a hub VNet, so you don't pay for a gateway in every spoke.

It's two settings on the peering. The hub side enables Allow gateway transit. The spoke side enables Use remote gateways. A spoke that already has its own gateway can't use a remote one.

Keep in mind that on-premises also needs routes back to the spoke prefixes, either by adding them to the Local Network Gateway or by using BGP.

Plan on 30 to 45 minutes for a new gateway, and occasionally longer. Azure is provisioning VMs, configuring networking and bringing up the gateway service, so it can't be rushed.

Use --no-wait in the CLI or deploy through an ARM/Bicep/Terraform pipeline so you aren't blocked. Deleting a gateway and recreating it is the slow path, so avoid it for simple changes. Many settings, like adding connections or changing BGP details, don't need a rebuild.

Resizing within a family is quicker than a rebuild, but still plan for a window. If a deployment seems stuck beyond an hour, check the Activity Log for the real error. Common causes are a GatewaySubnet that is too small, a missing Standard public IP for an AZ SKU, or a policy that blocks the resource type.

The difference is how Azure decides which traffic goes into the tunnel. Route-based gateways use the routing table. Policy-based gateways use fixed IP-address rules.

Choose route-based unless your on-premises device can only do policy-based. If you must match specific prefixes, a route-based gateway can still honor them through the UsePolicyBasedTrafficSelectors connection option.

A practical tip: if the vendor's guide says the device needs 'policy-based' selectors, ask whether it supports route-based as well. Most modern firewalls do, and route-based is what lets you add BGP, more tunnels and P2S later.

In the default setup, two gateway instances exist but only one is active. The other sits on standby and takes over if the active one is rebooted, updated or fails.

During a switchover the public IP stays the same, but all tunnels drop and have to re-establish. Microsoft quotes roughly 10-15 seconds for planned maintenance and 1-3 minutes for an unplanned failure, though real numbers depend on your device's re-negotiation speed.

That is the main reason teams move to active-active. It keeps a tunnel to both instances alive, so one failing doesn't force a full renegotiation.

To test your own recovery time, schedule a controlled reset during a maintenance window and watch how long your on-premises device takes to bring the tunnels back. Devices that re-negotiate slowly, or that cache the old SA, extend the outage more than Azure's own switchover does.

With two live tunnels, something has to decide which path each packet uses and what to do when one dies. BGP does that automatically.

Without BGP you'd maintain static routes for both tunnels on the on-premises device and rely on tunnel-monitoring tricks to fail over. With BGP, each tunnel advertises the Azure prefixes, Azure and your router can load-balance with ECMP, and a failed tunnel's routes are simply withdrawn.

It also keeps return traffic symmetric more often and removes the need to edit prefix lists when subnets change.

One caveat: BGP only helps if your on-premises device runs it properly on both tunnels. If it can't hold two BGP sessions, an active-active gateway with static routing still works, but you lose the automatic withdrawal and need to monitor each tunnel yourself.

Both connect on-premises to Azure, but one rides the public internet and the other uses a private circuit from a provider.

Many shops use ExpressRoute as the primary path and keep a S2S VPN as the backup.

Pricing models differ as well. VPN Gateway charges an hourly rate by SKU plus outbound data. ExpressRoute adds the circuit fee, the provider's charges and a gateway. Cost alone rarely decides it. Latency, throughput and whether the workload can tolerate internet variability usually do.

Peering connects VNets directly over the Microsoft backbone. VNet-to-VNet builds an IPsec tunnel through two gateways.

Start with peering. Pick VNet-to-VNet when a compliance rule demands IPsec between the networks.

Peering also supports global peering across regions, so the old reason for VNet-to-VNet, 'it's the only cross-region option', no longer holds. Also note that peering isn't transitive by default. If spoke A has to reach spoke B, you need a hub firewall with routes, or a gateway with BGP.

Put the VPN gateway in the hub, then peer each spoke to the hub with transit enabled in both directions. The gateway must exist before the spoke can use it.

az network vnet peering create -g rg-net -n hub-to-spoke1 \
  --vnet-name vnet-hub --remote-vnet vnet-spoke1 \
  --allow-vnet-access --allow-gateway-transit

az network vnet peering create -g rg-net -n spoke1-to-hub \
  --vnet-name vnet-spoke1 --remote-vnet vnet-hub \
  --allow-vnet-access --use-remote-gateways

After that, add the spoke prefixes to the on-premises side (LNG prefixes or BGP), and have P2S users re-download their client profile so they see the new routes.

Common mistakes: enabling Use remote gateways before the hub gateway has finished deploying, forgetting that the spoke can't have its own gateway, and not advertising the spoke ranges to the on-premises router. Whenever you add a peering after P2S is live, users must re-download the client profile, otherwise they won't have the spoke routes.

It uses NAT rules on the gateway. Instead of renumbering a network, you translate one overlapping range into a unique one that both sides agree on.

There are two rule types. Ingress rules translate the on-premises prefix as it enters Azure. Egress rules translate the Azure prefix as it leaves toward the remote site. Rules can be static (one-to-one) or dynamic (pooled), and you attach them to specific connections.

NAT needs a VpnGw2 or higher SKU. Basic and VpnGw1 don't support it.

Example: both sides use 10.1.0.0/16. You translate the on-premises range to 172.16.0.0/16 on ingress and the Azure range to 172.17.0.0/16 on egress. Each side then talks to the other's translated range. Remember that DNS answers and any app that embeds IP addresses in payloads need extra thought, because they will still carry the original addresses.

The gateway VMs need to receive and send internal control and management traffic that you can't see or enumerate. An NSG might block it, and the gateway can stop working or fail to deploy. Microsoft's guidance is simple: don't associate an NSG with GatewaySubnet.

Apply filtering where it's safe instead:

• NSGs on the destination subnets inside the VNet.
• Azure Firewall or an NVA in the hub for inspection.
• Firewall rules on the on-premises device.

The same caution applies to a 0.0.0.0/0 route on this subnet.

If someone already attached an NSG and the gateway went unhealthy, remove the association first and then reset the gateway. Azure Policy can block the association before it happens, which is a good safety net on large estates.

A standalone VPN gateway fits a single VNet or a small hub-and-spoke. Virtual WAN fits when you have many branches, multiple regions and want any-to-any transit without hand-building it.

• Dozens or hundreds of branches or SD-WAN devices.
• Need a Microsoft-managed hub with routing, security and VPN/ExpressRoute together.
• Want branch-to-branch transit through Azure's backbone.
• Need more aggregate S2S throughput through scale units.

Stay with a classic gateway when there are only one or two sites, you want fine control of the gateway, or cost matters more than automation.

Also compare operations. A classic gateway means you own the routing design, route tables and firewall insertion. Virtual WAN trades some of that control for automation, so teams with strict custom routing needs sometimes find it too opinionated.

You can resize within the same generation and family, for example VpnGw1AZ to VpnGw2AZ, without deleting the gateway. Expect a short connectivity interruption while instances restart, so do it in a maintenance window.

az network vnet-gateway update -g rg-net -n vpngw-hub --sku VpnGw2AZ

• Basic can't be resized to other SKUs. Delete and recreate, or migrate.
• Non-AZ to AZ SKUs and different generations need a migration or rebuild, not a simple resize.
• Check the public IP type first. AZ SKUs need a Standard static IP.

Before you resize, check your tunnel and P2S counts against the target SKU, confirm the target supports the features you use (NAT, for example, needs VpnGw2 or higher), and tell the on-premises team the tunnels will bounce. Take a screenshot of connection status first so you can compare afterwards.

A reset reboots the gateway instances. All tunnels drop and have to renegotiate. In an active-standby setup it forces a failover to the other instance, and the disruption usually lasts a few minutes.

az network vnet-gateway reset -g rg-net -n vpngw-hub

Use it as a last resort after checking configuration, shared keys and on-premises device logs. If only one tunnel is misbehaving, reset that connection from the portal first so unrelated tunnels stay up. Don't run a reset during business hours without telling the network owners.

Configuration is preserved. The public IP doesn't change.

Not all problems need a reset. If a single tunnel is down because of a key mismatch, reset won't fix it. Reset helps when the gateway looks wedged: stale SAs, a connection stuck in Connecting after you changed settings, or after you fixed something on the on-premises device.

By default Azure negotiates from a list of supported proposals. If your compliance team or device needs one exact combination, apply a custom policy to the connection. It works on route-based gateways, VpnGw1 and above.

az network vpn-connection ipsec-policy add -g rg-net \
  --connection-name cn-onprem \
  --ike-encryption AES256 --ike-integrity SHA384 --dh-group DHGroup24 \
  --ipsec-encryption GCMAES256 --ipsec-integrity GCMAES256 \
  --pfs-group PFS24 --sa-lifetime 27000 --sa-max-size 102400000

Both ends must use the same algorithms, DH and PFS groups. Lifetimes may differ, but the lower value wins. Once a policy is set, Azure offers only that combination, so a typo takes the tunnel down.

A good rollout order: agree the algorithm set with the on-premises team, update the device first on a standby tunnel if you have one, apply the policy to the Azure connection, then confirm both phases in the logs. If you later want to go back to Azure defaults, use ipsec-policy clear on the connection.

Users sign in to the Azure VPN Client with their Entra ID account, and the gateway validates the token. No certificates to issue or revoke.

On the gateway you configure three values: the tenant (issuer), the audience (the Azure VPN Client app ID) and the OpenVPN tunnel type. A tenant admin must grant consent for the enterprise app once.

• Works with OpenVPN only.
• Supports Conditional Access, MFA and group-based access.
• Clients download a profile and sign in with their corporate identity.

Offboarding is simple: disable the user in Entra ID and access ends.

Plan for a few operational details. Create a dedicated security group for VPN users and assign it to the enterprise app, so access is controlled by group membership. Combine this with Conditional Access to require a compliant device. The client app must be Azure VPN Client, so generic OpenVPN clients won't work here.

You upload the public data of a root certificate (base64 .cer content) to the gateway. Each client gets a client certificate signed by that root.

1. Create or use an internal root CA.
2. Upload the root's public key to the P2S configuration.
3. Issue client certificates from the root and install them in each user's store.
4. At connect time the client presents its cert, and the gateway checks the chain back to the root.

The private key of the root never leaves your control. The downside is operational: you handle distribution, expiry and revocation for every device.

Keep an eye on expiry. A client certificate that has expired fails silently from the user's point of view, and the gateway just rejects the handshake. Many teams automate issuance and renewal through Intune or a PKI, otherwise helpdesk tickets pile up once the first batch of certificates ages out.

Add the certificate's thumbprint to the revoked certificates list in the gateway's point-to-site configuration. After that, the gateway rejects new connections using that client cert.

• Get the thumbprint from the client certificate's details (no spaces).
• Add it under Revoked certificates and save the P2S configuration.
• Check whether any active session needs to be dropped manually.

If the root itself is compromised, remove the root certificate from the configuration. That invalidates every client certificate issued from it, so plan for reissuing them.

With Entra ID authentication this whole step isn't needed.

It helps to keep a record of every issued certificate, who it went to and its thumbprint, because the gateway only needs the thumbprint but you need to know which one belongs to the lost laptop. Document this before you need it.

A multi-site VPN means one Azure gateway, several on-premises sites. You create one Local Network Gateway and one connection per site. The gateway must be route-based.

1. Create a Local Network Gateway for each site with its own public IP and prefixes.
2. Create a separate connection per site with its own shared key.
3. Make sure no two sites' address prefixes overlap.
4. Stay within the tunnel limit of your SKU.

With BGP, Azure can also act as a transit hub, letting site A reach site B through the gateway. Without BGP, you'd have to engineer that yourself.

Operationally, give each site its own shared key and name the connections clearly, like cn-branch-pune, so logs make sense. If a site goes down you want to isolate it without touching the others, and separate connections let you reset just that tunnel.

/27 or larger. A /28 can work for a lone Basic gateway, but it leaves no room to grow.

A bigger subnet is needed when you add an active-active setup, coexist with an ExpressRoute gateway in the same subnet, or move to a different SKU. Some configurations, such as ExpressRoute with the maximum number of instances, ask for /26.

Resizing the subnet later means deleting the gateway, so sizing right upfront saves a 45-minute rebuild and an outage.

If your hub already has a smaller subnet, you can't simply grow it while a gateway is in it. You delete the gateway, change the subnet and recreate, so confirm the size in the design phase, not after go-live.

Forced tunneling sends all internet-bound traffic from Azure back to on-premises, typically so a corporate firewall can inspect it. You do it by making the VPN gateway the next hop for 0.0.0.0/0.

• With BGP: advertise 0.0.0.0/0 from the on-premises router. Azure learns it automatically.
• Without BGP: use a route table with 0.0.0.0/0 pointing at the virtual network gateway, and set up the connection and Local Network Gateway to allow the default route.

Watch for side effects. Azure services that need direct internet or platform access, like Windows activation, may break unless you exclude their ranges. It also adds latency and uses VPN bandwidth.

Pick OpenVPN when you have non-Windows users or tight firewalls, or when you want Entra ID authentication. SSTP only works from Windows, which rules it out for macOS, Linux and mobile.

• OpenVPN runs on TCP 443, so it passes most proxies and hotel networks.
• SSTP also uses 443 but is capped at 128 simultaneous connections.
• Entra ID auth requires OpenVPN.

IKEv2 is the third option. It's native on Windows and macOS and efficient, but its UDP ports are often blocked, so it's a bad fit for traveling staff.

For mixed fleets, publish OpenVPN as the default, and keep IKEv2 only for Windows or macOS users on trusted networks who want the native client. Retire SSTP unless you have a legacy Windows-only reason, since it's the least flexible of the three.

Microsoft publishes the SLA by SKU. At the time of writing, the commonly cited figures are:

The SLA covers the Azure gateway only. It does not cover your internet path or the on-premises device. To approach those numbers end to end, use active-active or zone-redundant gateways plus redundant on-premises devices. Always confirm the current figures on Microsoft's SLA page.

Remember composite availability. If your design needs 99.99% end to end, multiply the availability of every dependency: gateway, on-premises devices, ISP links and DNS. The gateway SLA alone doesn't make the whole path 99.99%.

Work from the outside in, and change one thing at a time.

1. Check the connection status and Resource Health in the portal.
2. Confirm the Local Network Gateway has the correct on-premises public IP and prefixes.
3. Compare the shared key on both sides character by character.
4. Verify IKE version, encryption, integrity, DH group and PFS match on both ends.
5. Make sure UDP 500 and UDP 4500 aren't blocked by the on-premises firewall or ISP.
6. Look for overlapping address spaces.
7. Confirm no NSG sits on the GatewaySubnet.
8. Run VPN troubleshooting from Network Watcher and read IKEDiagnosticLog.

Phase 1 failures usually mean keys or IKE proposals. Phase 2 failures usually mean traffic selectors or IPsec proposals. Also check the on-premises device log, because it often tells you which proposal Azure rejected.

A tunnel that goes up and down repeatedly usually has a timing, MTU or capacity issue, not a configuration typo. Start with the logs: TunnelDiagnosticLog shows each state change and the stated reason.

• Rekey mismatch: different SA lifetimes can cause drops during rekey. Align them.
• DPD timeouts: an overloaded or rate-limited on-premises device may miss keepalives.
• MTU and fragmentation: clamp TCP MSS (1350 is a common value) on the on-premises device.
• Policy-based selectors: mismatched traffic selectors reset the child SA.
• ISP instability: check for packet loss on the path.

Correlate the timestamps of the drops with CPU, memory and interface errors on the on-premises device before blaming Azure.

If the flapping started right after a change, roll that change back first, whether it was a policy edit, a new route or a firmware update on the on-premises device. Collect evidence with timestamps from both sides before opening a support case, because that cuts the back-and-forth.

Start by knowing the limits. A single IPsec tunnel tops out around 1 Gbps, regardless of how big the SKU is. Aggregate throughput comes from using several tunnels.

• Choose the right SKU, and Generation2 for higher numbers on VpnGw2 and up.
• Use active-active with BGP so ECMP spreads flows across tunnels.
• Pick efficient ciphers, such as GCMAES256, on both ends if your device supports them.
• Set TCP MSS properly to avoid fragmentation.
• Use VMs with accelerated networking so the endpoints aren't the bottleneck.
• Benchmark with multiple parallel flows. One flow always rides one tunnel.

If you need more than the gateway can give, move the heavy traffic to ExpressRoute or consider Virtual WAN.

Measure before and after. Use a tool such as iperf3 with several parallel streams between two VMs on each side, and keep the numbers. If a single flow is slow but the aggregate is fine, you've hit the per-tunnel cap, not a gateway problem.

IKEv2 builds the tunnel in a few short exchanges, then keeps it alive and refreshes the keys on a timer.

sequenceDiagram
    participant OP as On-prem VPN device
    participant AZ as Azure VPN gateway
    OP->>AZ: IKE_SA_INIT (proposals, DH, nonce)
    AZ-->>OP: IKE_SA_INIT (chosen proposal, DH, nonce)
    OP->>AZ: IKE_AUTH (identity, PSK auth, traffic selectors)
    AZ-->>OP: IKE_AUTH (auth, child SA accepted)
    Note over OP,AZ: IPsec child SA up, ESP traffic flows
    OP->>AZ: DPD keepalives
    OP->>AZ: CREATE_CHILD_SA (rekey)

1. IKE_SA_INIT negotiates algorithms and does the Diffie-Hellman exchange.
2. IKE_AUTH proves identity with the pre-shared key and sets up the first child SA.
3. Data phase: traffic is encrypted with ESP.
4. DPD detects a dead peer. Rekey replaces SAs before their lifetime or data limit runs out.

IKEv1 does the same job in two phases: main mode, then quick mode.

When troubleshooting, map symptoms to the phase. A failure at IKE_SA_INIT usually means no matching proposal. A failure at IKE_AUTH points to the shared key, identities or traffic selectors. A tunnel that is up but passes no traffic is usually a routing or NSG problem, not an IKE one. Azure's IKEDiagnosticLog shows which step failed.

The packet gets encrypted at the on-premises edge, crosses the internet, and is decrypted by the Azure gateway. After that it follows normal VNet routing.

flowchart LR
    A["On-prem host 10.20.1.5"] --> B["On-prem VPN device"]
    B -->|Route to 10.0.0.0/16, ESP encrypt| C((Internet))
    C --> D["Azure gateway public IP"]
    D -->|Decrypt| E["VNet routing"]
    E --> F["NSG on subnet"]
    F --> G["Azure VM 10.0.1.4"]

1. The host sends to the VM's private IP. Its default gateway forwards to the VPN device.
2. The device matches the Azure prefix, encrypts with ESP and sends it to the gateway's public IP.
3. The gateway decrypts and forwards inside the VNet using system routes and any UDRs.
4. The subnet's NSG evaluates the packet before it reaches the VM.

The reply returns the same way. The VM needs a route for the on-premises prefix pointing at the gateway, learned from the LNG prefixes or from BGP. If replies don't return, check that route first.

A useful trick: check effective routes on the VM's NIC and the on-premises router's route table for the destination prefix. If either side lacks the route, the packet never enters the tunnel, and you'll waste time reading IKE logs for a routing problem.

Both sides advertise what they can reach. The Azure gateway learns on-premises prefixes and installs them in the VNet's effective routes with next hop Virtual network gateway. It advertises the VNet prefix, and the prefixes of peered VNets that use gateway transit, back to the on-premises router.

• Spokes with Use remote gateways receive the on-premises routes through peering.
• A route table with Propagate gateway routes disabled will ignore them.
• A more specific UDR beats a BGP route. Equal prefixes prefer the UDR.

Check the result instead of guessing:

az network vnet-gateway list-learned-routes -g rg-net -n vpngw-hub
az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-hub --peer 10.20.255.1

One common surprise is route priority. If the same prefix is learned from both ExpressRoute and VPN, ExpressRoute wins at equal prefix length. If a more specific route comes from the VPN, it wins regardless. Always read the effective routes before assuming which path is used.

Use metrics for quick health and alerts, and diagnostic logs for the why. Send the logs to a Log Analytics workspace.

• Metrics: tunnel ingress/egress bytes and packets, tunnel packet drops, BGP peer status, BGP routes learned and advertised, P2S connection count.
• Logs: GatewayDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog, IKEDiagnosticLog, P2SDiagnosticLog.

Alert on tunnel status changes, BGP peer status dropping, and sustained packet drops. Example query for disconnect events (adjust column names to your workspace):

AzureDiagnostics
| where Category == "TunnelDiagnosticLog"
| where status_s == "Disconnected"
| project TimeGenerated, remoteIP_s, status_s, stateChangeReason_s
| order by TimeGenerated desc

Resource Health and Network Watcher connection troubleshooting give you the platform view.

Set the alert thresholds against a baseline. Look at a normal week of tunnel throughput first, then alert on drops such as a tunnel's egress falling to zero during business hours. Route alerts to the network team, not just to a shared mailbox, because tunnel problems are time-sensitive.

Use ExpressRoute as the primary and a site-to-site VPN as the backup over the internet. Both gateways can live in the same VNet and share GatewaySubnet, which needs to be /27 or larger.

• Run BGP on both so failover is automatic.
• Advertise the same prefix lengths on both paths. Azure prefers ExpressRoute for equal prefixes.
• Use zone-redundant SKUs for both gateways.
• Add a second ExpressRoute circuit at a different peering location for site-level redundancy.
• Use active-active VPN and two on-premises devices.

Test it. Shut down the circuit during a maintenance window and confirm traffic moves to the VPN, then confirm it moves back. Also remember the VPN path has lower bandwidth, so know which workloads will suffer during failover.

A final check is DNS. Private DNS zones, conditional forwarders and on-premises resolvers must work on both paths, otherwise names fail even though IP connectivity moved over correctly.

This gives you IPsec encryption on top of a private circuit, which some compliance regimes require. Traffic goes through ExpressRoute, but the tunnel is built between the gateway's private IP and your on-premises device's private IP.

1. Have ExpressRoute private peering working with an ExpressRoute gateway.
2. Enable a private IP address on the VPN gateway.
3. Create a Local Network Gateway using the on-premises device's private IP.
4. Create the connection and choose to use the private IP address.
5. Make sure private peering advertises the needed private ranges.

The VPN gateway and the ExpressRoute gateway coexist in the VNet, and throughput is bounded by the VPN gateway SKU, not the circuit size.

Two practical limits: the device on the on-premises side must support IPsec with private addressing, and you should check MTU, since the IPsec overhead reduces the usable payload on the circuit. Treat it as a design that needs a test plan before production.

Make sure traffic in both directions passes through the firewall, using route tables on three places.

• GatewaySubnet route table: spoke prefixes with next hop = the firewall's private IP. Don't use 0.0.0.0/0 here.
• Spoke route table: on-premises prefixes (or 0.0.0.0/0) with next hop = the firewall. Disable gateway route propagation so the spoke doesn't bypass it.
• Firewall rules: allow only the flows you want, such as on-prem to a specific spoke subnet.

flowchart LR
    OP[On-premises] --> GW["VPN gateway"]
    GW -->|UDR: spoke prefix via firewall| FW["Azure Firewall"]
    FW --> SP["Spoke VM"]
    SP -->|UDR: on-prem via firewall| FW
    FW --> GW

Verify with effective routes on a spoke NIC. Asymmetric routing is the usual failure here, so check both directions.

A tip when it doesn't work: use IP flow verify and the firewall logs. If the firewall shows the request but no reply, the return route is missing. If the firewall shows nothing, the first hop route is wrong. Also remember to allow the same flows in the firewall in both directions.