Site-to-Site VPN
Site-to-site VPN connects an on-premises network to Azure over encrypted IPsec/IKE tunnels. For AZ-700, expect requirements around high availability, gateway SKU selection, policy-based versus route-based VPN, custom IPsec/IKE policy, and troubleshooting tunnel establishment.
Core Components
| Component | Purpose |
|---|---|
| Virtual network gateway | Azure-side VPN gateway deployed into GatewaySubnet. |
| Local network gateway | Azure representation of the on-premises VPN device and address prefixes. |
| Connection | Links the Azure gateway to the local network gateway with shared key and policy settings. |
| IPsec/IKE policy | Defines encryption, integrity, DH group, PFS, and SA lifetime parameters. |
S2S and BGP Resource Responsibilities
A site-to-site design needs both sides represented in Azure. The virtual network gateway is the managed Azure VPN endpoint. The local network gateway describes the on-premises endpoint, including its public IP address, reachable prefixes, and, when BGP is used, its autonomous system number and BGP peer IP. The connection binds those two gateway objects and carries the shared key, connection mode, IPsec/IKE policy, and BGP enablement.
BGP configuration therefore belongs on both the virtual network gateway and the local network gateway; Application Gateway, Azure Firewall, and Front Door do not participate in the BGP session. Use a route-based VPN gateway for BGP. Ensure the Azure and on-premises ASNs and peer addresses are valid, the on-premises device permits TCP 179 inside the tunnel, and advertised prefixes do not overlap. See BGP with Azure VPN Gateway.
Policy-Based vs Route-Based
- Policy-based VPN uses static encryption domains. It is older and more limited.
- Route-based VPN uses routes and tunnel interfaces. It is the preferred option for most Azure VPN designs.
- Use route-based VPN for BGP, active-active, point-to-site coexistence, and more flexible routing.
High Availability
- Active-standby is simpler but has failover time.
- Active-active uses two gateway instances with two public IPs.
- Zone-redundant SKUs improve resiliency against zone failure.
- For best HA, use redundant on-premises VPN devices and multiple tunnels.
Point-to-Site VPN
Point-to-site VPN connects individual clients to Azure. Know protocol and authentication combinations.
| Authentication | Typical use |
|---|---|
| Microsoft Entra ID | User-based modern auth with OpenVPN. |
| Certificate | Client certificate authentication, useful for controlled devices. |
| RADIUS | Integration with existing network authentication infrastructure. |
How to Choose P2S Authentication
RADIUS is the bridge when users must authenticate with an existing on-premises Active Directory or network-policy system. Deploy a RADIUS server such as Network Policy Server, make it reachable from the VPN gateway, configure the server address and shared secret on the gateway, and let RADIUS validate the user's domain credentials and policy. The VPN gateway is the RADIUS client; Key Vault and Application Proxy do not replace this authentication exchange.
Microsoft Entra ID provides cloud user authentication and Conditional Access for supported P2S designs. It requires OpenVPN and the Azure VPN Client. Configure the tenant, audience or application ID, and issuer values correctly, then download and import a fresh client profile after gateway changes. Certificate authentication validates a client certificate chained to a trusted root certificate uploaded to Azure and is useful for managed devices, but it introduces certificate issuance, renewal, and revocation work.
Separate tunnel protocol from authentication method. OpenVPN can support Entra ID, certificates, or RADIUS depending on the design, while IKEv2 and SSTP have different client and authentication support. The right answer follows the identity source, client platforms, Conditional Access requirement, and protocol compatibility. See Microsoft Learn guidance for RADIUS authentication and Microsoft Entra ID authentication.
Troubleshooting Checklist
- Verify gateway SKU, gateway type, VPN type, and active-active settings.
- Check shared key mismatch.
- Check IPsec/IKE parameter mismatch.
- Check on-premises public IP and NAT traversal.
- Check local network gateway prefixes and BGP routes.
- Check NSGs and UDRs after the tunnel is up.
- For P2S, check downloaded profile, client address pool overlap, DNS, and authentication configuration.
VPN Gateway Diagnostic Logs
Azure VPN Gateway can send four diagnostic log categories to a Log Analytics workspace. Select the log by the failure stage rather than opening every category at once. IKEDiagnosticLog provides verbose IKE/IPsec negotiation messages and is the primary log when a site-to-site tunnel fails to establish or disconnects because of IPsec negotiation. It exposes problems such as mismatched pre-shared keys, unsupported encryption or integrity algorithms, Diffie-Hellman and PFS mismatches, traffic-selector problems, and failed security-association negotiation. TunnelDiagnosticLog records the tunnel's historical connect and disconnect state, so use it to establish when a working tunnel dropped and then correlate that timestamp with the detailed IKE log. RouteDiagnosticLog records static route changes and routes learned through BGP; use it when the tunnel is connected but prefixes are missing, changing, or being learned incorrectly. GatewayDiagnosticLog audits gateway configuration changes and is useful when a failure coincides with a deployment, maintenance event, or configuration update. For policy-based VPN gateways, Microsoft documents only GatewayDiagnosticLog and RouteDiagnosticLog as available.
| Log category | What it tells you | Use it when |
|---|---|---|
IKEDiagnosticLog | Verbose IKE and IPsec negotiation, security associations, proposals, and errors. | The tunnel cannot establish, repeatedly renegotiates, or disconnects for an IPsec-related reason. |
TunnelDiagnosticLog | Historical tunnel connected and disconnected events. | You need the failure timeline or want to identify the exact timestamp for deeper IKE analysis. |
RouteDiagnosticLog | Static route updates and BGP route activity. | The tunnel is up but networks are unreachable or expected routes are absent. |
GatewayDiagnosticLog | VPN gateway configuration and administrative changes. | A connectivity change may be related to reconfiguration, deployment, or maintenance. |
Investigation sequence: if the tunnel is down, start with IKEDiagnosticLog. If the outage happened in the past, use TunnelDiagnosticLog to find the disconnect time and correlate it with IKE events. If the tunnel reports Connected but traffic still fails, move to RouteDiagnosticLog, effective routes, NSGs, UDRs, and device routing. Correlate GatewayDiagnosticLog whenever the timing suggests a configuration or platform change. In Log Analytics, these records can be filtered from AzureDiagnostics with a query such as AzureDiagnostics | where Category == "IKEDiagnosticLog" | sort by TimeGenerated desc. See Troubleshoot Azure VPN Gateway using diagnostic logs.
Lab
- Create a route-based VPN gateway.
- Create a local network gateway object.
- Create a connection with a shared key and custom IPsec/IKE policy.
- Configure P2S with Microsoft Entra authentication and test client connection.
Feature Deep Dive
Gateway SKU Selection
Gateway SKU affects throughput, tunnel count, BGP support, availability zone support, and active-active options. In scenario questions, SKU is rarely random. Look for requirements such as high throughput, zone resiliency, many tunnels, BGP, or active-active connectivity.
BGP with VPN
BGP lets Azure and on-premises exchange routes dynamically. Use it when routes change, when multiple paths exist, or when active-active designs need automatic failover. Without BGP, you rely more heavily on static local network gateway prefixes and manual route management.
Custom IPsec/IKE Policy
Custom policy matters when the on-premises device requires specific encryption, integrity, DH group, PFS group, or SA lifetime values. If the tunnel does not establish and the shared key is correct, policy mismatch is one of the first things to check.
Point-to-Site User Experience
P2S is not only the tunnel. Users also need a client profile, routes, DNS, authentication, and authorization. A connected VPN client can still fail to reach a workload if the client address pool overlaps, DNS is wrong, or NSGs block the path.
Design Decision Table
| Requirement | Design choice |
|---|---|
| Modern user VPN with Entra sign-in | OpenVPN with Microsoft Entra ID authentication. |
| Device certificate-based user VPN | Point-to-site with certificate authentication. |
| Dynamic route exchange with branch network | Route-based VPN with BGP. |
| Two active Azure tunnel endpoints | Active-active VPN gateway. |
| Custom crypto required by appliance | Custom IPsec/IKE policy. |
Scenario Workshop: Tunnel Up, App Still Down
Scenario: The VPN connection status is Connected, but on-premises users cannot reach a VM in Azure. This is a classic AZ-700 troubleshooting scenario because the tunnel being up only proves phase 1 and phase 2 negotiation worked. It does not prove routing, DNS, NSG, or host firewall correctness.
| Layer | What to validate |
|---|---|
| Routing | On-premises route to Azure prefix, Azure route back to on-premises prefix, BGP learned routes or local network gateway prefixes. |
| Security | NSG inbound rules, guest OS firewall, Azure Firewall/NVA rules if forced tunneling is used. |
| Name resolution | Whether users resolve the app name to the Azure private IP or to a stale/public address. |
| Application | Whether the service listens on the expected port and interface. |
Packet Flow: Site-to-Site VPN
- On-premises client sends traffic to an Azure private IP.
- On-premises router sends the packet to the VPN device.
- The VPN device encrypts the packet into the IPsec tunnel.
- Azure VPN Gateway decrypts the packet and injects it into the VNet route domain.
- Azure applies routes and NSGs on the destination path.
- Return traffic must know how to get back to the on-premises prefix.
Authentication Notes for P2S
Microsoft Entra authentication is user-centric and modern, but it depends on supported client and protocol choices. Certificate authentication is strong for managed devices but requires certificate lifecycle management. RADIUS is useful when the organization already has network authentication infrastructure and policies it wants to reuse.