What's changed: Deepened AZ-700 Chapter 2 (ja figures; comparison tables/scenarios/FAQ/traps/deep paragraphs in all sections)
2.1Site-to-Site and P2S with VPN Gateway
Understand VPN Gateway that connects on-premises or individual clients to Azure over an encrypted tunnel. Site-to-site (S2S), point-to-site (P2S), and VNet-to-VNet are the basis of AZ-700 hybrid networking.
To securely connect on-prem and Azure over the internet, you establish an encrypted VPN tunnel, handled by the VPN Gateway.
2.1.1Types of VPN connections
- Site-to-site (S2S): connect an entire on-prem site to Azure via an IPsec tunnel (the on-prem side is represented by a local network gateway).
- Point-to-site (P2S): connect individual client PCs to the VNet (e.g., remote work).
- VNet-to-VNet: connect two VNets via VPN gateways (an alternative/complement to peering).
- SKU and performance: the gateway SKU determines throughput, tunnel count, and redundancy (active-active).
Common on AZ-700: connect a whole site = S2S, connect individual PCs = P2S, represent on-prem side = local network gateway, redundancy = active-active. Distinguish VPN (encrypted tunnel over internet) from ExpressRoute (private circuit, next section).
A VPN Gateway is deployed into a dedicated GatewaySubnet; reserve it during subnet design.
A VPN Gateway is built from a virtual network gateway representing the VNet side (type = VPN, placed in GatewaySubnet), a local network gateway representing on-prem (the site’s address space and the VPN device’s public IP), and a connection between them (shared key / PSK). The SKU (VpnGw1–5; AZ variants are zone-redundant) governs throughput, tunnel count, BGP support, and SLA, and active-active (two public IPs on the gateway) provides redundancy. S2S comes in route-based (multiple tunnels, coexists with P2S, recommended) and policy-based (single static tunnel); enabling BGP exchanges routes dynamically (on-prem ASN and Azure’s default ASN 65515). P2S protocols are OpenVPN/IKEv2/SSTP with certificate/Entra ID/RADIUS authentication. VNet-to-VNet can also use peering, but use VPN when crossing tenants or needing BGP/tunnels.
| Type | Connects | Notes |
|---|---|---|
| Site-to-site (S2S) | A whole site (VPN device) | IPsec; route/policy-based; BGP-capable |
| Point-to-site (P2S) | Individual client PCs | OpenVPN/IKEv2/SSTP; cert/Entra/RADIUS |
| VNet-to-VNet | Two VNets | Use VPN for cross-tenant or BGP needs |
Scenario: keep HQ permanently connected to Azure while letting remote workers connect individually to the VNet. → Create a route-based VPN Gateway; connect HQ via S2S (represented by a local network gateway) and remote workers via P2S (Entra ID auth). Route-based allows S2S and P2S to coexist on one gateway.
FAQ: Q. Route-based vs policy-based? → A. Prefer route-based (multiple tunnels, P2S coexistence, BGP); policy-based is a static single-tunnel option for older devices. Q. VNet-to-VNet: peering or VPN? → A. Peering for low latency/high bandwidth; VPN when crossing tenants or needing BGP/encrypted tunnels.
Trap: “policy-based VPN can also run P2S and multiple S2S tunnels” is wrong—those are route-based features. Also “the local network gateway is the Azure-side gateway” is wrong—the Azure side is the virtual network gateway; the local one represents on-prem. VPN is over the internet—distinct from ExpressRoute (private circuit).
2.1.2Section summary
- VPN Gateway = encrypted tunnels (S2S = site, P2S = client, VNet-to-VNet)
- On-prem side = local network gateway, redundancy = active-active
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which VPN type connects an entire on-prem site to Azure via an IPsec tunnel?
Q2. You want individual remote client PCs to VPN into the VNet. Which type?
Q3. In a site-to-site VPN, what represents the on-prem network (address space and VPN device public IP) in Azure?