How can Azure VPN Gateway be configured to establish secure connectivity between on-premises networks and Azure?

A common enterprise requirement is to connect an existing on-premises network to Azure without exposing internal application traffic directly to the public internet.

Azure VPN Gateway provides a site-to-site VPN capability that establishes an IPsec/IKE tunnel between an on-premises VPN device and an Azure virtual network. Microsoft documents the site-to-site architecture using an Azure VPN Gateway, a Local Network Gateway representing the on-premises network, and a VPN connection.

A simplified architecture is:

                 On-Premises
              +---------------+
              |               |
              | Applications  |
              | Servers       |
              | Network       |
              +-------+-------+
                      |
               VPN Device
                      |
                Public IP
                      |
                IPsec / IKE
                      |
                +-----+------+
                |            |
                v            v
          Azure VPN Gateway
                |
                v
          Azure VNet
                |
       +--------+--------+
       |                 |
       v                 v
    Web/App            Database
    Subnet              Subnet

The first architectural step is to define the network address spaces.

For example:

On-Premises: 10.10.0.0/16
Azure VNet:  10.20.0.0/16

These address ranges must be planned carefully. Overlapping address spaces can create routing problems and should be avoided when designing interconnected networks.

Core Azure components

A typical S2S deployment includes:

Virtual Network

The Azure network that contains the workloads.

Gateway Subnet

A dedicated subnet used by the virtual network gateway.

Azure VPN Gateway

The Azure-side VPN termination point.

Local Network Gateway

An Azure resource representing the on-premises site. It contains information such as the on-premises VPN device's public IP and the on-premises address prefixes.

Connection

The object that connects the Azure VPN Gateway to the Local Network Gateway.

On-premises VPN Device

The physical or virtual network device responsible for establishing the tunnel.

Configuration flow

The configuration can be approached as:

Create VNet
   |
   v
Create GatewaySubnet
   |
   v
Create Public IP
   |
   v
Create VPN Gateway
   |
   v
Create Local Network Gateway
   |
   v
Configure On-Premises VPN Device
   |
   v
Create S2S Connection
   |
   v
Validate Tunnel
   |
   v
Validate Application Connectivity

Microsoft's documented portal procedure follows this general sequence and uses an IPsec site-to-site connection with the shared key configured on both sides.

Authentication and encryption

A common configuration uses a pre-shared key.

The key must match between the Azure connection and the on-premises VPN device. Microsoft recommends using a strong production key rather than the simple example values used in tutorials.

IKEv2 is a common choice for current configurations and is used in Microsoft's current examples.

For environments with more advanced security requirements, certificate-based site-to-site authentication is also supported in appropriate configurations. Microsoft documents certificate authentication using X.509 certificates, Azure Key Vault and a user-assigned managed identity.

High availability

A production design should not stop at:

On-Premises
     |
     v
One VPN Tunnel
     |
     v
Azure

A more resilient architecture can use an active-active VPN Gateway and establish tunnels to both gateway instances. Microsoft recommends configuring tunnels to each gateway instance for highly available connectivity in active-active configurations.

For more complex enterprise networks, BGP can be used to exchange routing information dynamically between Azure VPN Gateway and on-premises VPN devices. Microsoft documents BGP support for cross-premises S2S configurations and explains how BGP can propagate routes between connected networks.

Troubleshooting should be layered

If an application cannot connect to an on-premises database, do not immediately assume the VPN is broken.

Investigate in this order:

Application
   |
   v
DNS
   |
   v
Route
   |
   v
Network Security
   |
   v
VPN Tunnel
   |
   v
On-Premises Firewall
   |
   v
Target Server
   |
   v
Application Port

A tunnel showing Connected does not automatically prove that every application flow is working.

The enterprise principle is:

VPN connectivity is a network foundation, not an end-to-end application availability guarantee.