3.2 Site-to-Site (S2S) VPN & High Availability
Key Takeaways
- The Local Network Gateway (LNG) resource represents the on-premises VPN device, containing its public IP address (or FQDN), static address spaces, and BGP peering settings.
- Custom IPsec/IKE policies allow explicit configuration of cryptographic algorithms (e.g., GCMAES256, AES-256, SHA-256, DH Group 14/24, PFS 24) to satisfy strict regulatory compliance.
- Azure VPN Gateway uses ASN 65515 by default; when peering with on-premises networks, on-premises BGP routers must use a different ASN.
- APIPA BGP IP addresses (169.254.21.0/24 to 169.254.22.0/24) enable dedicated BGP peering over multiple active-active tunnels without consuming routable RFC 1918 addresses.
- Cross-premises transit routing enables branch-to-branch connectivity through Azure VPN Gateway by propagating BGP routes learned from one on-premises site to other connected sites.
Site-to-Site (S2S) VPN connections extend corporate on-premises datacenters and branch offices into Azure Virtual Networks over encrypted IPsec/IKE tunnels. Enterprise deployments require precise cryptographic alignment, dynamic route propagation via Border Gateway Protocol (BGP), and multi-tunnel high availability architectures.
1. Local Network Gateway (LNG) Architecture
A Local Network Gateway (LNG) is a dedicated Azure resource that represents your on-premises VPN endpoint to Azure. It is not an actual gateway appliance; rather, it is a configuration object containing metadata about the remote site.
+---------------------------------------------------------------------------------------------------+
| AZURE S2S CONFIGURATION CONSTRUCTS |
| |
| +-----------------------------+ +-----------------------------------+ |
| | Virtual Network Gateway | | Local Network Gateway | |
| | | | | |
| | * Represents Azure Gateway | | * Represents On-Prem VPN Device | |
| | * Public IP: 20.50.10.1 | | * Remote IP: 198.51.100.25 (or | |
| | * GatewaySubnet Allocation | | FQDN: vpn.contoso.com) | |
| | * Azure ASN: 65515 | | * Remote Address Spaces: | |
| | * Azure BGP IP: 10.100.255.4| | 192.168.0.0/16, 172.16.0.0/12 | |
| +-----------------------------+ | * On-Prem ASN: 65001 | |
| \ / * On-Prem BGP IP: 192.168.1.1 | |
| \ / +-----------------------------------+ |
| \ / |
| +-----------------------------------+ |
| | Connection Resource | |
| | | |
| | * Connection Type: IPsec (S2S) | |
| | * Shared Key (PSK) | |
| | * Enable BGP: True/False | |
| | * Custom IPsec/IKE Policy | |
| +-----------------------------------+ |
+---------------------------------------------------------------------------------------------------+
Key Parameters of the Local Network Gateway
- Gateway IP Address / FQDN: The external, public IPv4 address of the on-premises firewall or VPN concentrator. If the on-premises device uses a dynamic public IP assigned by an ISP, you can specify a Fully Qualified Domain Name (FQDN) that updates via dynamic DNS.
- Address Spaces (Static Routing): The list of on-premises IP address prefixes that Azure must route across the VPN tunnel. When BGP is disabled, Azure injects these exact prefixes into the VNet's effective routing table with the next hop set to
VirtualNetworkGateway. - BGP Settings (Dynamic Routing): When dynamic routing is used, the LNG defines the on-premises BGP Peer ASN (Autonomous System Number) and the BGP Peering IP Address. If BGP is enabled, Azure automatically learns routes from the on-premises router and ignores the static address spaces defined in the LNG for traffic routing.
2. IPsec/IKE Cryptographic Parameters & Custom Policies
IPsec tunnel establishment occurs in two distinct phases:
- Phase 1 (IKE SA): Authenticates the endpoints, negotiates security parameters, and establishes a secure management channel.
- Phase 2 (IPsec / Child SA): Negotiates the encryption, integrity, and data protection algorithms used to encrypt actual data packets transmitting across the tunnel.
Default vs. Custom IPsec/IKE Policy
Azure VPN Gateway provides a default cryptographic configuration designed for broad interoperability. However, to comply with strict compliance frameworks (e.g., FIPS 140-2, PCI-DSS, Zero Trust), network engineers can define a Custom IPsec/IKE Policy on the Connection resource.
| Cryptographic Parameter | Phase | Default Azure Settings | Supported Custom Policy Options |
|---|---|---|---|
| IKE Encryption | Phase 1 | AES256, AES128, 3DES | GCMAES256, GCMAES128, AES256, AES128, DES3, DES |
| IKE Integrity | Phase 1 | SHA256, SHA1, MD5 | SHA384, SHA256, SHA1, MD5 |
| DH Group (Diffie-Hellman) | Phase 1 | DHGroup2 (1024-bit), DHGroup14 (2048-bit) | DHGroup24, DHGroup14, ECP384, ECP256, DHGroup2, DHGroup1, None |
| IPsec Encryption | Phase 2 | GCMAES256, AES256, AES128, 3DES | GCMAES256, GCMAES192, GCMAES128, AES256, AES128, DES3, DES, None |
| IPsec Integrity | Phase 2 | GCMAES256, SHA256, SHA1, MD5 | GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5 |
| PFS Group (Perfect Forward Secrecy) | Phase 2 | None | PFS24, PFS14, ECP384, ECP256, PFS2048, PFS2, PFS1, None |
| IKE SA Lifetime | Phase 1 | 28,800 seconds (8 hours) | 300 to 28,799 seconds (customizable) |
| IPsec SA Lifetime (Time) | Phase 2 | 27,000 seconds (7.5 hours) | 300 to 26,999 seconds (customizable) |
| IPsec SA Lifetime (Kilobytes) | Phase 2 | 102,400,000 KB | 1,024 to 2,147,483,647 KB |
| DPD Timeout | Keepalive | 45 seconds | 9 to 3,600 seconds |
[!WARNING] Cryptographic Suite Mismatches: If you configure a custom IPsec policy on Azure, the on-premises device must match all parameters exactly across both Phase 1 and Phase 2. A single mismatch in Diffie-Hellman Group, PFS Group, or Encryption/Integrity algorithm will cause tunnel negotiation to fail during the
IKE_AUTHorCREATE_CHILD_SAexchanges.
3. Dynamic Routing: BGP over S2S VPN & APIPA Peering
Border Gateway Protocol (BGP) is the standard routing protocol used to exchange dynamic network topology information between Azure and on-premises networks.
BGP Autonomous System Numbers (ASN)
- Azure Default ASN:
65515(reserved by Azure for VPN Gateways and ExpressRoute). - Custom ASN Support: You can configure a custom 16-bit or 32-bit ASN for Azure VPN Gateway (e.g.,
65010). - Reserved ASNs (Cannot be used):
0,65534,65535,12076(Microsoft WAN),8075(Microsoft internal), and public ASNs not owned by your organization. - Constraint: The on-premises BGP ASN must be different from the Azure VPN Gateway ASN. eBGP requires distinct ASNs to exchange routing tables.
APIPA BGP Addressing in Active-Active Topologies
In standard single-tunnel deployments, BGP peering occurs between the Azure GatewaySubnet private IP (e.g., 10.100.255.4) and the on-premises LAN/VTI interface IP (e.g., 192.168.1.1).
In Active-Active multi-tunnel topologies, configuring BGP across redundant public IP links using standard RFC 1918 IPs can cause routing conflicts and asymmetric paths. To solve this, Azure supports Automatic Private IP Addressing (APIPA) for BGP:
- Azure allows assignment of APIPA link-local addresses from the
169.254.21.0/24and169.254.22.0/24ranges. - Instance 0 is assigned an APIPA IP (e.g.,
169.254.21.1). - Instance 1 is assigned a distinct APIPA IP (e.g.,
169.254.22.1). - On-premises edge routers configure their BGP peering sessions targeting these specific APIPA endpoints across the respective IPsec VTIs, ensuring isolated, point-to-point BGP sessions that do not consume private enterprise address space.
+---------------------------------------------------------------------------------------------------+
| ACTIVE-ACTIVE DUAL-ROUTER FULL-MESH BGP TOPOLOGY |
| |
| +---------------------------------------------------------------------+ |
| | Azure Virtual Network | |
| | GatewaySubnet (ASN: 65515) | |
| | | |
| | +---------------------------+ +---------------------------+ | |
| | | Gateway Instance 0 | | Gateway Instance 1 | | |
| | | Public IP: 20.50.10.1 | | Public IP: 20.50.10.2 | | |
| | | APIPA BGP: 169.254.21.1 | | APIPA BGP: 169.254.22.1 | | |
| | +---------------------------+ +---------------------------+ | |
| +------------------+---------------------------------+----------------+ |
| | | |
| Tunnel 1-1 | Tunnel 1-2 Tunnel 2-1 | Tunnel 2-2 |
| (169.254.21.1) (169.254.22.1) (169.254.21.1) (169.254.22.1) |
| | | | | |
| v v v v |
| +---------------------------------------------------------------------+ |
| | +---------------------------+ +---------------------------+ | |
| | | On-Prem Edge Router 1 | | On-Prem Edge Router 2 | | |
| | | Public IP: 198.51.100.10 | | Public IP: 198.51.100.20 | | |
| | | APIPA BGP: 169.254.21.2 | | APIPA BGP: 169.254.22.2 | | |
| | +---------------------------+ +---------------------------+ | |
| | On-Premises Datacenter (ASN: 65001) | |
| +---------------------------------------------------------------------+ |
+---------------------------------------------------------------------------------------------------+
4. Multi-Site Topologies & Cross-Premises Transit Routing
Azure VPN Gateway supports connecting multiple on-premises branch offices and datacenters to a centralized hub VNet.
Multi-Site VPN Configuration Rules
- Overlapping IP Prevention: None of the connected on-premises sites may have overlapping IP address prefixes with each other or with any Azure VNets.
- Route-Based Gateway Required: Multi-site connectivity requires a Route-Based VPN Gateway SKU (VpnGw1-5). Basic Policy-based gateways are limited to 1 S2S tunnel.
- Local Network Gateway per Site: A dedicated LNG and Connection object must be created for each physical site.
Branch-to-Branch Transit Routing with BGP
By default, Azure VPN Gateway does not forward traffic between connected S2S sites (Site A cannot communicate with Site B through Azure) when using static routing.
To enable Cross-Premises Transit Routing:
- Enable BGP on the Azure Virtual Network Gateway and all connected Local Network Gateways.
- When Site A advertises prefix
10.1.0.0/16via BGP to Azure (ASN 65515), Azure automatically re-advertises10.1.0.0/16to Site B (ASN 65002) with Azure's ASN prepended. - Packets from Site B destined for Site A transmit across the Site B IPsec tunnel to the Azure GatewaySubnet, which routes the packets across the Site A IPsec tunnel without requiring dedicated point-to-point leased lines between physical offices.
A network security team establishes a Site-to-Site VPN tunnel between an Azure VNet and an on-premises Fortinet firewall using a custom IPsec/IKE policy. Phase 1 IKE negotiation completes successfully, but Phase 2 IPsec tunnel negotiation fails. Diagnostic logs show error ID 'CHILD_SA_PROPOSAL_REJECTED'. Which configuration mismatch is the root cause of this failure?
An enterprise network engineer is deploying an Active-Active Azure VPN Gateway with two Standard Public IPs to connect to dual on-premises edge routers over dynamic BGP. To eliminate the consumption of routable RFC 1918 subnets and avoid routing conflicts across the four tunnels, which addressing technique must be implemented for the BGP peering sessions?
An organization has two branch offices (Branch 1 and Branch 2) connected via independent Site-to-Site VPN tunnels to a central Azure Virtual Network Gateway. Users at Branch 1 need to securely communicate with servers located at Branch 2. Currently, traffic between Branch 1 and Branch 2 fails. What must the administrator configure to enable branch-to-branch transit communication through Azure?