AKS CrashLoopBackOff, Pending Pods, and NotReady Nodes — The Real Fixes Engineers Use

Planning GuideSite-to-Site VPNGateway SKUsBGP & IPsec

Azure Site-to-Site VPN Prerequisites: Network
Planning, Gateway Requirements, IPsec, and Routing

Half of what determines whether a Site-to-Site VPN deployment goes smoothly happens before the gateway exists at all — the subnet size, the SKU, the address space plan, and the ASN choice are all decisions that are painful or impossible to change once traffic is flowing. Get the prerequisites right, and the actual gateway creation is the boring, predictable part.

Current status, verified

Azure is actively consolidating VPN Gateway SKUs. The Basic SKU and the original VpnGw1–VpnGw5 SKUs are being phased out in favor of zone-redundant AZ SKUs (VpnGw1AZ through VpnGw5AZ), which Microsoft now recommends for all new deployments. After June 2026, Azure will attempt to automatically migrate remaining Standard and High Performance SKU gateways — and that migration can fail outright if the gateway subnet is too small for the target SKU.

This guide's prerequisites reflect the current, recommended path: plan for an AZ SKU and a correctly-sized gateway subnet from the start, rather than the legacy defaults many older tutorials still describe.

/27 minimum

Required GatewaySubnet size for every current SKU except the retiring Basic tier — plan larger for future headroom

AZ SKUs

VpnGw1AZ–VpnGw5AZ are zone-redundant and now Microsoft's recommended default for all new gateway deployments

UDP 500 + 4500

Plus IP protocol 50 (ESP) — the exact outbound ports/protocol your on-premises firewall must permit for IKEv2/IPsec

100 tunnels

The practical ceiling for S2S VPN tunnels on a single VPN Gateway — beyond that, Virtual WAN is the recommended path instead

Table of Contents

1. 01Gateway SKU Selection: The Current AZ SKU Migration
2. 02GatewaySubnet Sizing: Getting This Wrong Is Expensive Later
3. 03Address Space Planning: The Non-Overlap Requirement
4. 04Public IP Requirements
5. 05The Local Network Gateway: Representing Your On-Premises Side
6. 06IPsec/IKE Parameters and Firewall Port Requirements
7. 07BGP and ASN Planning
8. 08Route-Based vs Policy-Based: The Routing Decision
9. 09Step-by-Step: The Complete Prerequisites Checklist
10. 10Anti-Patterns
11. 11Frequently Asked Questions

A Site-to-Site VPN connection is, mechanically, not complicated — an Azure VPN Gateway and an on-premises VPN device negotiate an IPsec tunnel, and traffic flows. What actually determines whether that deployment goes smoothly is almost entirely decided before the gateway is created: whether the address spaces on both sides overlap, whether the subnet reserved for the gateway is sized correctly for the SKU you'll actually need, whether the SKU itself is one Microsoft still recommends deploying today, and whether your on-premises firewall permits the specific ports and protocol the tunnel needs. Every one of these is either difficult or genuinely disruptive to change after the fact — a gateway subnet that's too small can't simply be resized once other resources have claimed the surrounding address space, and an overlapping address range discovered after deployment means renumbering a live network. This guide works through every prerequisite that actually matters, in the order that makes the later decisions easier rather than harder.

Figure 1 — Six planning gates, each one expensive to fix after deployment

Every gate constrains what's possible at the gates after it — the SKU determines the minimum viable gateway subnet size, the gateway subnet's actual size determines whether a future SKU upgrade or automatic migration can succeed, and the address space decision has to be correct before any of the rest is worth doing at all. Working through them in this order avoids discovering a blocking constraint after deployment.

01Gateway SKU Selection: The Current AZ SKU MigrationCurrent Status

This is the prerequisite most likely to be answered incorrectly by outdated guidance, because it's actively changing. Microsoft's current documentation is explicit: the zone-redundant AZ SKUs (VpnGw1AZ through VpnGw5AZ) are recommended for all new deployments, while the original VpnGw1–VpnGw5 SKUs are slated for migration and should not be used for new gateways.

SKU category	Status	Recommendation
Basic	Being retired — use the Basic IP migration tool	Migrate existing; never use for new deployments
Standard / High Performance	Legacy — subject to automatic migration after June 2026	Migrate proactively rather than waiting for automatic migration
VpnGw1–VpnGw5	Slated for migration	Should not be used to create new VPN gateways
VpnGw1AZ–VpnGw5AZ	Current, zone-redundant	Recommended for all new deployments

Automatic migration after June 2026 can fail — and gateway subnet size is exactly why

Microsoft's stated plan: after June 2026, Azure attempts to automatically migrate gateways still running the Standard SKU (upgraded to VpnGw1AZ) or High Performance SKU (upgraded to VpnGw2AZ). If Azure encounters constraints — explicitly including an insufficient gateway subnet size — the automatic migration cannot complete. This is precisely why gateway subnet sizing (Section 2) is a forward-looking prerequisite even for a gateway you're deploying today on a currently-supported SKU: undersizing it now can block an automatic migration you don't control the timing of, two years from now.

AZ SKUs also deliver measurably better performance, not just zone redundancy

Beyond the resilience benefit of zone redundancy, Microsoft's own guidance notes that VpnGw1AZ and VpnGw2AZ specifically deliver better performance than their non-AZ predecessors at the equivalent tier. Choosing an AZ SKU for a new deployment isn't purely a compliance-with-current-recommendations decision — it's also, independently, the better-performing option at a comparable price point.

02GatewaySubnet Sizing: Getting This Wrong Is Expensive LaterCorrection

A commonly-repeated piece of folklore — "a /29 GatewaySubnet is the minimum" — is only true for the Basic SKU, which is being retired. For every other current SKU, including every AZ SKU Section 1 recommends, the minimum is /27.

Scenario	Minimum GatewaySubnet size
Basic SKU only	/29 — but Basic is being retired; don't plan around this number for new deployments
All other SKUs (including all AZ SKUs)	/27 or larger
ExpressRoute/VPN Gateway coexistence configuration	Larger than /27 — check the specific coexistence documentation for the exact requirement

Plan larger than the minimum — this subnet can't easily grow later

Microsoft's own guidance directly suggests creating a gateway subnet larger than /27 specifically to leave room for future configurations — active-active deployments, coexistence with ExpressRoute, or a future SKU upgrade all consume more addresses from this subnet than a minimal single-instance deployment. Because a subnet's address range is difficult to change once other resources are deployed around it, the cost of over-provisioning slightly today is low, and the cost of under-provisioning is a genuine redesign later.

Azure CLI — create a correctly-sized GatewaySubnetaz network vnet subnet create \ --resource-group myResourceGroup \ --vnet-name myVNet \ --name GatewaySubnet \ --address-prefixes 10.0.255.0/26 # /26 here, not the /27 minimum - deliberate headroom for a future # active-active upgrade or ExpressRoute coexistence, per the guidance # above. The subnet MUST be named exactly "GatewaySubnet" - Azure # specifically looks for this name.

03Address Space Planning: The Non-Overlap RequirementFoundation

The single most fundamental prerequisite, and the one that's genuinely painful to fix after the fact: the on-premises address space and the Azure virtual network's address space must not overlap. If they do, routing becomes ambiguous — Azure and your on-premises network can't both claim authority over the same IP range across the tunnel.

• Audit every on-premises range before choosing the Azure VNet's address space. Include every subnet that will need to reach Azure, not just the immediately obvious ones — a range that seems unused today can still conflict with a planned future connection.
• Check peered VNets too, not just the directly-connected one. If the VNet hosting the gateway is peered with other VNets that will also route through this connection, their address spaces need to be non-overlapping with on-premises as well.
• Document the full address plan before requesting the gateway subnet. This is the point in the process where a spreadsheet or IPAM tool pays for itself — a clear record of every range in play prevents the "wait, that's already used somewhere else" discovery mid-deployment.

Overlapping address spaces discovered after deployment mean renumbering a live network — plan around this explicitly

There's no clean fix for overlapping address spaces after a VPN connection is already carrying production traffic — the resolution is renumbering one side's network, which is disruptive, time-consuming, and carries real operational risk for anything already depending on the existing addressing. This is worth treating as a hard, non-negotiable gate before any gateway is created, not a detail to sort out during deployment.

04Public IP RequirementsPrerequisite

The Azure VPN Gateway needs a public IP address to establish the tunnel with your on-premises device, and the requirement here has tightened alongside the SKU consolidation covered in Section 1.

Requirement	Detail
Public IP SKU	Standard SKU public IP is required when creating a new VPN gateway — Basic SKU public IPs are tied to the retiring Basic gateway tier
Allocation method	Static, for a production gateway you don't want to change unexpectedly
IPv6	Not supported on the Basic gateway SKU — another reason to plan around a current, non-Basic SKU
Active-active gateways	Require two public IP addresses — one per gateway instance

Azure CLI — create the Standard SKU public IP the gateway requiresaz network public-ip create \ --resource-group myResourceGroup \ --name pip-vpngw-prod \ --allocation-method Static \ --sku Standard # Static allocation + Standard SKU together - this is the current # requirement, not optional for a new gateway deployment.

Your on-premises VPN device's public IP (or FQDN) needs to be known and stable too

This prerequisite runs in both directions — Azure needs a stable public IP on its side, and the on-premises VPN device needs a stable public IP or a resolvable FQDN on its side, since this is exactly what gets configured into the Local Network Gateway resource (Section 5). If the on-premises device is behind a dynamic IP with no FQDN, resolve that before proceeding — the tunnel configuration depends on knowing this address ahead of time.

05The Local Network Gateway: Representing Your On-Premises SideConcept

The Local Network Gateway is a distinct Azure resource — not the on-premises device itself, but Azure's representation of it, telling the Azure VPN Gateway how to reach and route to your on-premises network.

• Name and public IP/FQDN. A friendly name for the resource, and the public IP address (or FQDN) of your actual on-premises VPN device — this is what Azure uses as the tunnel's destination.
• Address prefixes. The on-premises network ranges that should route through this connection. Azure consults this list to decide which destination IPs get routed toward the tunnel.
• BGP peer IP and ASN, if using BGP. When BGP is in play (Section 7), the Local Network Gateway also carries your on-premises device's BGP peer IP address and autonomous system number.

Azure CLI — create the Local Network Gatewayaz network local-gateway create \ --resource-group myResourceGroup \ --name lgw-onprem-hq \ --gateway-ip-address 203.0.113.10 \ --local-address-prefixes 192.168.0.0/16 # gateway-ip-address is YOUR on-premises device's public IP. # local-address-prefixes are the on-prem ranges Azure should route # toward this tunnel - get this list complete and accurate up front.

You need one Local Network Gateway per distinct on-premises site or peer

If you're connecting to multiple physical sites, or setting up VNet-to-VNet connectivity via a VPN gateway connection, each distinct peer gets its own Local Network Gateway resource. This is also where the address prefix list needs to be genuinely complete — an omitted on-premises subnet here means Azure has no route toward it, producing a connection that establishes successfully but can't actually reach part of the on-premises network.

Figure 2 — What your on-premises firewall must permit outbound, precisely

Site-to-Site VPN connections use IPsec/IKE, requiring exactly three things permitted outbound from the on-premises firewall: UDP 500 and UDP 4500 for IKE negotiation and NAT traversal, and IP protocol 50 (ESP) for the actual encrypted tunnel traffic. Protocol 50 specifically is easy to overlook, since it isn't a port in the conventional TCP/UDP sense — a firewall configured only in terms of TCP/UDP ports can silently block it while appearing to allow the VPN traffic.

06IPsec/IKE Parameters and Firewall Port RequirementsDeep Dive

Beyond the ports covered in Figure 2, there's a real decision to make about which specific cryptographic parameters govern the tunnel — and whether you need to specify them explicitly at all.

Option	When to use it	SKU support
Default IPsec/IKE policy	Your on-premises device supports Azure's default parameter set — the simplest path, works for most modern devices	All SKUs
Custom IPsec/IKE policy	Your on-premises device requires specific algorithms, key lifetimes, or Diffie-Hellman groups not in the default set	All SKUs except Basic

A custom policy lets you specify exactly one combination of encryption, integrity, and Diffie-Hellman group parameters for a given connection — it's an all-or-nothing override of the default, not a partial adjustment. Before configuring a custom policy, check your on-premises VPN device vendor's documentation for their specific Azure-compatible parameter recommendations; most major vendors (Cisco, Palo Alto, Fortinet, and others) publish validated configuration guides with the exact parameter combinations known to interoperate correctly.

IKEv2 is generally preferable to IKEv1 where your device supports it

IKEv2 supports in-place rekeys, avoiding the brief reconnection that IKEv1 requires when a security association's key lifetime expires. If your on-premises device supports both, and you're seeing connections reconnect at unexpected times with IKEv1, switching to IKEv2 is a documented fix for exactly this symptom — worth choosing IKEv2 from the outset if your device's compatibility allows it, rather than discovering the IKEv1 reconnection behavior in production.

Policy-based gateways can no longer be configured through the Azure portal

As of October 1, 2023, policy-based VPN gateways can only be configured via PowerShell or Azure CLI — they're no longer available as an option in the Azure portal. This is relevant to prerequisite planning specifically because it affects tooling choice: if a policy-based gateway is genuinely required (rare for new deployments — Section 8 covers when), plan for CLI/PowerShell-based deployment and management from the start, not portal-based workflows.

07BGP and ASN PlanningDeep Dive

BGP (Border Gateway Protocol) is optional for a Site-to-Site connection with static, simple routing needs, but becomes valuable — and for some scenarios, necessary — once the routing gets more complex: multiple on-premises sites, redundant tunnels, or dynamic route propagation without manual maintenance.

Requirement	Detail
SKU support	Supported on all SKUs except Basic
Gateway type	Route-based gateways only — not supported on policy-based gateways
ASN format	32-bit (4-byte) ASNs are supported, configurable in decimal format via CLI, PowerShell, or SDK
ASN source	You can use your own public ASNs or private ASNs, for both on-premises and Azure sides
Reserved ASNs	Certain ASN ranges are reserved and cannot be assigned to your on-premises VPN device when connecting to an Azure VPN gateway — check current reserved ranges before finalizing your ASN choice

Azure CLI — create a route-based gateway with BGP enabled and an explicit ASNaz network vnet-gateway create \ --resource-group myResourceGroup \ --name vng-azure-prod \ --vnet myVNet \ --public-ip-addresses pip-vpngw-prod \ --gateway-type Vpn \ --vpn-type RouteBased \ --sku VpnGw1AZ \ --asn 65515 \ --no-wait # --sku VpnGw1AZ, not VpnGw1 - the current recommended SKU per # Section 1. --asn sets Azure's side of the BGP session explicitly.

Without BGP, route maintenance is manual and doesn't scale past simple topologies

A static-routing (non-BGP) connection requires the address prefixes on both sides to be manually and completely specified in the Local Network Gateway configuration, and any change to on-premises network topology means updating that configuration by hand. For a single site with a stable, simple address range, this is entirely reasonable. For multiple sites, redundant tunnels, or a topology that changes with any regularity, BGP's dynamic route propagation removes an ongoing manual maintenance burden that static routing doesn't handle gracefully at scale.

08Route-Based vs Policy-Based: The Routing DecisionDeep Dive

This decision shapes several of the prerequisites already covered — it determines BGP availability, custom IPsec/IKE policy support, and even which management tools are available.

Aspect	Route-Based	Policy-Based
Recommended for	Most deployments — the standard modern default	Specific legacy device compatibility requirements only
BGP support	Yes	No
Point-to-Site support	Yes — required for any P2S configuration	No
SKU availability	All current SKUs	Basic SKU only
Management tooling	Portal, CLI, PowerShell	CLI/PowerShell only, as of Oct 1, 2023
IKE version support	IKEv1 and IKEv2, on most current SKUs	IKEv1 only

In most cases, this decision is already made for you by the SKU recommendation in Section 1

Because policy-based gateways are tied to the Basic SKU — which is being retired — and because Section 1's recommendation is to deploy on a current AZ SKU regardless, route-based is the practical default for essentially any new deployment. Reach for policy-based specifically and only when a legacy on-premises VPN device genuinely cannot support route-based configuration, and even then, budget for eventual migration given the Basic SKU's retirement trajectory.

09Step-by-Step: The Complete Prerequisites ChecklistHow-To

1. Audit and document every address range on both sides — confirm zero overlap

   Include on-premises ranges, the planned Azure VNet range, and any peered VNet ranges that will route through this connection. This is the one prerequisite that's genuinely disruptive to fix after deployment — get it right first.

2. Choose a current AZ SKU sized for your expected throughput and tunnel count

   Select from VpnGw1AZ through VpnGw5AZ based on required aggregate throughput and the number of S2S/P2S connections needed — not from the legacy VpnGw1-5 or Basic SKUs, which are being phased out.

3. Reserve a GatewaySubnet of /27 minimum, ideally /26 or larger

   Name it exactly GatewaySubnet. Size it with headroom for active-active configuration, ExpressRoute coexistence, or a future automatic SKU migration — not just the current single-instance minimum.

4. Provision a Standard SKU, statically-allocated public IP

   Required for any current gateway SKU. For an active-active deployment, provision two.

5. Confirm your on-premises VPN device's public IP or FQDN is stable and known

   This becomes the Local Network Gateway's configured endpoint — resolve any dynamic-IP situation on the on-premises side before proceeding.

6. Verify outbound UDP 500, UDP 4500, and IP protocol 50 (ESP) are permitted through the on-premises firewall

   Confirm this explicitly with whoever manages the on-premises firewall — protocol 50 specifically is easy to miss in a firewall configured primarily around TCP/UDP port rules.

7. Decide route-based vs policy-based, and BGP vs static routing

   Default to route-based unless a specific legacy device constraint says otherwise. Choose BGP if the topology involves multiple sites, redundant tunnels, or routes likely to change over time; static routing is fine for a single, stable site.

8. If using BGP, select and validate ASNs on both sides

   Confirm your chosen ASNs aren't in Azure's reserved range, and decide whether to use existing public/private ASNs or select new private ones specifically for this connection.

9. Prepare the pre-shared key (or certificate, if applicable) securely

   Generate a strong pre-shared key and have a secure channel ready to share it with whoever configures the on-premises device — this shouldn't be sent over an insecure channel like plain email.

10. Budget 30-45 minutes for gateway creation itself, plus tunnel negotiation time

    Gateway creation is a genuinely time-consuming Azure operation — plan the deployment window accordingly rather than expecting near-instant provisioning.

10Anti-PatternsTraps

Anti-pattern	Why it feels right	Why it isn't
Deploying a new gateway on VpnGw1-5 or Basic SKU	"These are the SKUs most tutorials still reference"	Both are being phased out — the current recommendation is the zone-redundant AZ SKUs for any new deployment
Creating a /29 GatewaySubnet "because that's the documented minimum"	"Smaller is more efficient"	/29 is only valid for the retiring Basic SKU — every current SKU needs /27 minimum, and undersizing can block a future automatic migration entirely
Choosing the Azure VNet address range without auditing on-premises ranges first	"We'll pick something that seems unused"	An overlap discovered after deployment means renumbering a live network — audit both sides before committing to either
Assuming ESP (protocol 50) is automatically allowed if TCP/UDP VPN ports are open	"We opened the VPN ports already"	Protocol 50 isn't a conventional TCP/UDP port and firewalls configured primarily around ports can silently block it — verify explicitly
Sizing the GatewaySubnet for only the current, single-instance deployment	"We don't need active-active or ExpressRoute today"	Undersizing now can block a future SKU upgrade, active-active configuration, or the automatic post-June-2026 migration — plan headroom deliberately
Choosing policy-based routing without a specific documented device constraint	"It's simpler conceptually"	Tied to the retiring Basic SKU, loses BGP and Point-to-Site support, and as of October 2023 can only be managed via CLI/PowerShell — route-based is the practical default

Key Takeaways

→Deploy on a current AZ SKU, not VpnGw1-5 or Basic. Both legacy tiers are being phased out, with automatic migration attempted after June 2026 — plan for VpnGw1AZ through VpnGw5AZ from the start.

→/27 is the real GatewaySubnet minimum for any current SKU. The commonly-repeated /29 figure applies only to the retiring Basic tier — plan /26 or larger for genuine headroom.

→Undersizing the gateway subnet today can block an automatic migration you don't control the timing of. Azure's stated migration plan explicitly cites insufficient subnet size as a blocking constraint.

→Non-overlapping address spaces are non-negotiable, and painful to fix later. Audit every range — on-premises, Azure VNet, and any peered VNets — before committing to any of them.

→Three specific things must be open outbound on the on-premises firewall. UDP 500, UDP 4500, and IP protocol 50 (ESP) — the last one is easy to miss in a ports-only firewall configuration.

→Route-based is the practical default for new deployments. It's required for BGP and Point-to-Site, works on every current SKU, and remains portal-manageable — policy-based lost portal support in October 2023.

→Beyond roughly 100 S2S tunnels, Virtual WAN is the recommended path instead of VPN Gateway. Know this ceiling before architecting a large multi-site topology around a single gateway.

Frequently Asked Questions

What's the minimum size for an Azure VPN Gateway's subnet?

For every current gateway SKU except the retiring Basic tier, the minimum GatewaySubnet size is /27. A commonly-repeated figure of /29 as "the minimum" is accurate only for the Basic SKU specifically, which Microsoft is actively phasing out — planning around that number for a new deployment on a current, recommended SKU (the zone-redundant AZ SKUs) will undersize the subnet. Microsoft's own guidance further recommends creating a gateway subnet larger than /27 to leave room for future configurations such as active-active deployment or ExpressRoute coexistence, both of which consume more addresses than a minimal single-instance setup. Given that undersizing this subnet can also block Azure's planned automatic SKU migration process for legacy gateways after June 2026, erring toward a larger subnet (/26 or bigger) from the outset is the safer default.

Which VPN Gateway SKU should I use for a new deployment?

A zone-redundant AZ SKU — VpnGw1AZ through VpnGw5AZ, sized according to your required aggregate throughput and expected number of S2S/P2S connections. Microsoft's current guidance is explicit that these SKUs are recommended for all new VPN gateway deployments, while the original VpnGw1 through VpnGw5 SKUs (without the AZ suffix) are slated for migration and shouldn't be used to create new gateways, and the Basic SKU is being retired entirely with a dedicated migration tool provided for existing deployments. Beyond following current recommendations, the AZ SKUs also deliver zone redundancy (resilience against a single datacenter failure within the region) and, specifically for VpnGw1AZ and VpnGw2AZ, measurably better performance than their non-AZ predecessors at a comparable tier.

What ports does a Site-to-Site VPN need open on my on-premises firewall?

Three things, specifically: outbound UDP port 500 and outbound UDP port 4500, both used for IKE (Internet Key Exchange) tunnel negotiation and NAT traversal, plus IP protocol 50 (ESP — Encapsulating Security Payload), which carries the actual encrypted tunnel data. All three need to be permitted outbound from your on-premises VPN device for the tunnel to establish and pass traffic. Protocol 50 is the one most likely to be overlooked, because it isn't a conventional TCP or UDP port — a firewall configuration written purely in terms of TCP/UDP port rules can silently block ESP traffic while appearing to have "the VPN ports" open, producing a connection that negotiates successfully (since 500/4500 are open) but fails to actually pass encrypted data. Explicitly verify protocol 50 is permitted, don't infer it from UDP 500/4500 being open.

Do I need BGP for a Site-to-Site VPN connection?

Not necessarily — it depends on your routing complexity. For a single on-premises site with a stable, well-defined address range, static routing (manually specifying address prefixes in the Local Network Gateway configuration) is entirely sufficient and simpler to set up. BGP becomes valuable, and in some cases necessary, once the topology involves multiple on-premises sites, redundant tunnels needing automatic failover, or on-premises network ranges that change with any regularity — situations where manually maintaining and updating static route lists becomes an ongoing operational burden. BGP is supported on all current gateway SKUs except Basic, but only on route-based gateways, not policy-based ones — another reason route-based is generally the better default choice for a new deployment, since it keeps BGP available as an option even if you don't need it on day one.

Related FAVRITE Articles

• Hub-and-Spoke vs Azure Virtual WAN: Which Network Architecture Wins?
• Azure Network Security Group Rules Explained: Inbound, Outbound, Priority, and Default Rules
• Designing a Multi-Region Azure Architecture for High Availability and Disaster Recovery
• Enterprise Network Segmentation in Azure: Architecture Patterns That Actually Scale