2.1 Site-to-Site (S2S) VPN Connectivity
📘Microsoft Azure Networking Solutions (AZ-700)
What is a Site-to-Site (S2S) VPN?
A Site-to-Site VPN creates a secure, encrypted connection between:
- An on-premises network (for example, a company data center)
- An Azure Virtual Network (VNet)
This connection happens over the public internet, but all traffic is encrypted using IPsec/IKE, so data stays private.
Once implemented:
- Azure resources can communicate with on-premises systems
- On-premises systems can communicate with Azure resources
- Communication feels like one extended private network
Why S2S VPN Is Used (Exam Perspective)
In AZ-700, S2S VPN is used when:
- You need permanent connectivity between Azure and on-premises
- ExpressRoute is not required or not available
- You want secure hybrid networking
Core Components Required for S2S VPN
To implement an S2S VPN, all of the following components are mandatory.
1. Virtual Network (VNet)
- This is the Azure network where your cloud resources live
- It must have:
- A valid address space (for example:
10.1.0.0/16)
- A valid address space (for example:
- This address space must not overlap with the on-premises network
📌 Exam rule:
Overlapping IP address ranges will cause the VPN to fail.
2. Gateway Subnet
- A special subnet inside the VNet
- Must be named exactly:
GatewaySubnet - Used only by the VPN gateway
Key requirements:
- Cannot host VMs or other services
- Should be large enough (recommended
/27or larger) - Only one GatewaySubnet per VNet
📌 Exam tip:
If the GatewaySubnet is missing or named incorrectly, the VPN gateway deployment fails.
3. Virtual Network Gateway (VPN Gateway)
This is the Azure VPN device that handles:
- Encryption
- Decryption
- Tunnel management
Important settings:
- Gateway type: VPN
- VPN type:
- Route-based (recommended and exam-preferred)
- Policy-based (legacy, limited)
- SKU:
- Determines throughput, number of tunnels, and features
- Examples: VpnGw1, VpnGw2, VpnGw3
📌 Exam rule:
- Route-based VPN is required for:
- BGP
- Active-Active gateways
- Most modern scenarios
4. Local Network Gateway
This represents the on-premises side inside Azure.
It includes:
- Public IP address of the on-premises VPN device
- On-premises address prefixes
- Example:
192.168.1.0/24
- Example:
📌 Think of it as an Azure configuration object that describes:
“This is the remote network I want to connect to.”
5. On-Premises VPN Device
This is the physical or virtual VPN device running on-premises.
Requirements:
- Must support IPsec/IKE
- Must have a public IPv4 address
- Must support:
- IKEv1 or IKEv2
- AES encryption
- SHA hashing
- DH groups
📌 Exam note:
Azure supports many vendor VPN devices, but configuration compatibility matters.
6. VPN Connection
This is the object that links:
- Virtual Network Gateway (Azure)
- Local Network Gateway (on-premises)
Key settings:
- Connection type: Site-to-site (IPsec)
- Shared key (PSK):
- Must match on both sides
- IKE protocol version
- Optional: BGP enabled
Step-by-Step Implementation Flow (Exam-Friendly Order)
Azure expects the implementation in a specific order.
Step 1: Create the Virtual Network
- Define address space
- Create subnets
- Add GatewaySubnet
Step 2: Create the Virtual Network Gateway
- Select VPN gateway
- Choose Route-based VPN
- Assign a public IP address
- Choose appropriate SKU
⏳ Deployment can take 30–45 minutes
Step 3: Create the Local Network Gateway
- Enter on-premises public IP
- Enter on-premises address ranges
Step 4: Create the VPN Connection
- Link both gateways
- Configure shared key
- Enable BGP (if required)
Step 5: Configure the On-Premises VPN Device
- Match:
- Shared key
- Encryption settings
- IKE version
- Address prefixes
Step 6: Validate the Connection
- Check connection status in Azure
- Test traffic flow between networks
Routing in Site-to-Site VPN
Routing controls how traffic flows between Azure and on-premises.
Static Routing
- Uses manually defined address prefixes
- Simple but less flexible
- No automatic updates
BGP (Border Gateway Protocol)
- Dynamic routing protocol
- Automatically exchanges routes
- Required for:
- Multiple tunnels
- Active-Active gateways
- Complex hybrid networks
📌 Exam rule:
- BGP requires Route-based VPN
- ASN values must be configured correctly
Security and Encryption
S2S VPN uses IPsec/IKE for security.
Key security features:
- Data encryption
- Authentication using shared keys
- Tunnel integrity protection
Common encryption settings:
- AES256
- SHA256
- DH Group 14 or higher
📌 Azure enforces strong cryptography by default.
High Availability and Resiliency
Azure provides built-in resiliency options.
Active-Standby (Default)
- One active tunnel
- Automatic failover
Active-Active VPN Gateway
- Two active instances
- Requires:
- Route-based VPN
- BGP
- Multiple tunnels
📌 Exam favorite:
Active-Active gateways improve availability and throughput.
Monitoring and Troubleshooting
Azure provides several tools to monitor S2S VPN.
Azure Portal
- Connection status (Connected / Disconnected)
- Ingress and egress traffic
Azure Monitor and Logs
- VPN diagnostic logs
- Tunnel failures
- Authentication errors
Common Issues (Exam Focus)
| Issue | Cause |
|---|---|
| VPN not connecting | Shared key mismatch |
| No traffic flow | Incorrect address prefixes |
| Tunnel drops | Incompatible encryption |
| Deployment failure | GatewaySubnet missing or too small |
Limitations to Remember (Exam)
- S2S VPN uses internet, not private circuits
- Throughput depends on gateway SKU
- Latency is higher than ExpressRoute
- IP overlap is not supported
Key Exam Takeaways
✔ GatewaySubnet is mandatory
✔ Route-based VPN is preferred
✔ Address spaces must not overlap
✔ Shared key must match on both sides
✔ BGP requires route-based VPN
✔ VPN Gateway SKU affects performance
✔ S2S VPN uses IPsec/IKE
