Azure Site-to-Site VPN Setup: A Practical Guide for Azure Admins

Why Site-to-Site VPNs Matter

Picture this: Your company’s New York office has a legacy ERP system running on a local server. Meanwhile, your Azure-based analytics platform in West Europe needs to pull data from that server for real-time reporting. Emailing CSV files or using unsecured connections isn’t an option—security and efficiency are non-negotiable. A Site-to-Site VPN creates a secure, encrypted tunnel between your on-premises network and Azure, letting your resources communicate as if they’re on the same network. I’ve seen this setup save countless hours of manual data transfers while keeping auditors happy.

Understanding Site-to-Site VPNs is critical because it ties into networking, security, and hybrid cloud concepts—core pillars of Azure administration. Let’s get into the nuts and bolts.

Understanding the Core Concepts

A Site-to-Site VPN in Azure uses IPsec/IKE (Internet Key Exchange) to establish a secure connection between your on-premises network and an Azure Virtual Network (VNet). Think of it as a private tunnel through the public internet. Here’s what you need to know:

Virtual Network Gateway: This is Azure’s side of the VPN. It’s a managed service that handles encryption, routing, and connection management. You’ll choose between policy-based or route-based gateways (route-based is more flexible and common).
Local Network Gateway: This represents your on-premises VPN device, defining its public IP and the address spaces of your local network.
Connection: This is the logical link between the Virtual Network Gateway and Local Network Gateway, configured with a shared key for authentication.
On-Premises VPN Device: Your firewall or router (e.g., Cisco, Juniper, or Fortinet) that supports IPsec/IKE. Azure’s documentation lists compatible devices—check it before you start.

One thing I’ve learned the hard way: not all VPN devices play nice with Azure. Early in my career, I spent hours troubleshooting a connection only to realize the client’s old router didn’t support IKEv2 properly. Always verify compatibility upfront.

Step-by-Step Implementation

Let’s set up a Site-to-Site VPN between your on-premises network and Azure. I’ll assume you have an Azure VNet and an on-premises network with a compatible VPN device. Here’s how to do it, step by step.

Step 1. Prepare Your Environment

Before you touch Azure, gather these details:

On-premises public IP: The external IP of your VPN device.
On-premises address space: The private IP ranges (e.g., 192.168.0.0/16) you want Azure to reach.
Azure VNet details: The VNet’s address space (e.g., 10.0.0.0/16) and a dedicated subnet for the gateway (e.g., 10.0.255.0/27). The gateway subnet must be named GatewaySubnet.
Shared key: A strong, pre-shared key for IPsec authentication (think of it like a password both sides agree on).

Pro tip: Document these details in a spreadsheet. When you’re troubleshooting at 2 a.m., you’ll thank yourself.

Step 2. Create the Virtual Network Gateway

In the Azure portal, navigate to Create a resource > Networking > Virtual network gateway.
Configure the basics:
- Name: Something like VNet1-GW.
- Region: Match your VNet’s region.
- Gateway type: Select VPN.
- VPN type: Choose Route-based (unless your device requires policy-based).
- SKU: Start with VpnGw1 for cost-efficiency; scale up if needed.
- Virtual network: Select your VNet.
- Public IP address: Create a new one or use an existing one.
Click Review + create and wait. This can take 20-45 minutes—Azure’s provisioning isn’t instant.

Step 3. Create the Local Network Gateway

Go to Create a resource > Networking > Local network gateway.
Configure:
- Name: E.g., OnPrem-LNG.
- IP address: Enter your on-premises VPN device’s public IP.
- Address space: Add your on-premises network’s private IP ranges (e.g., 192.168.0.0/16).
- Region: Same as your Virtual Network Gateway.
Create the resource.

Step 4. Configure the On-Premises VPN Device

This step depends on your device, but you’ll need to configure it to match Azure’s settings:

IPsec/IKE settings: Use IKEv2 or IKEv1, AES-256 encryption, SHA-256 hashing, and DH Group 2 or higher.
Azure gateway IP: Grab the public IP from your Virtual Network Gateway.
Shared key: You’ll set this in the next step.

I once worked with a Fortinet firewall where the client forgot to enable Dead Peer Detection (DPD). The connection kept dropping silently—check your device’s DPD settings!

Step 5. Create the Connection

In the Azure portal, go to your Virtual Network Gateway > Connections > Add.
Configure:
- Name: E.g., VNet1-to-OnPrem.
- Connection type: Select Site-to-site (IPsec).
- Local network gateway: Choose the one you created.
- Shared key: Enter a secure key (e.g., a 32-character random string).
Click OK to create the connection.

Step 6. Verify the Connection

In the Azure portal, check the Connection status under your Virtual Network Gateway. It should say Connected.
On your on-premises device, verify the tunnel is up.
Test connectivity by pinging a resource in Azure from your on-premises network (ensure NSGs and firewalls allow ICMP).

Here’s a quick Azure CLI command to check the connection status:

az network vpn-connection show --name VNet1-to-OnPrem --resource-group MyResourceGroup --query "connectionStatus"

If it returns "Connected", you’re golden. If not, it’s troubleshooting time.

Common Challenges and Solutions

Setting up a Site-to-Site VPN sounds straightforward, but things can go wrong. Here are issues I’ve run into and how to fix them.

Issue 1. Connection Fails to Establish

Cause: Mismatched IPsec/IKE settings.
Fix: Double-check encryption, hashing, and DH group settings on both Azure and your VPN device. Azure’s default settings (AES-256, SHA-256, IKEv2) are strict—your device must match exactly.
Tip: Use Azure’s Connection Troubleshooter in the portal. It’s not perfect, but it can point you in the right direction.

Issue 2. Traffic Not Flowing

Cause: Routing issues or NSG/firewall rules blocking traffic.
Fix: Ensure your on-premises device routes the Azure VNet’s address space through the VPN tunnel. In Azure, check Network Security Groups (NSGs) and User-Defined Routes (UDRs). For example, allow TCP/UDP traffic on relevant ports.

Example: Add an NSG rule to allow traffic from your on-premises subnet:

az network nsg rule create \
  --resource-group MyResourceGroup \
  --nsg-name MyNSG \
  --name AllowOnPrem \
  --priority 100 \
  --source-address-prefixes 192.168.0.0/16 \
  --destination-address-prefixes 10.0.0.0/16 \
  --destination-port-ranges '*' \
  --access Allow \
  --protocol '*'

Issue 3. Intermittent Drops

Cause: Idle timeouts or DPD issues.
Fix: Configure DPD on your VPN device and set Azure’s connection to “persistent.” I’ve also seen NAT traversal issues with some routers—enable NAT-T if needed.

Issue 4. Slow Performance

Cause: Low gateway SKU or network congestion.
Fix: Upgrade to a higher SKU (e.g., VpnGw2 or VpnGw3) for better throughput. Monitor bandwidth usage with Azure Monitor to identify bottlenecks.

One time, a client’s VPN was dropping because their ISP was throttling UDP traffic. Switching to TCP-based IKEv1 fixed it, but it’s a rare case—stick with IKEv2 unless you hit this wall.

Best Practices and Recommendations

Here’s what I’ve learned from years of managing Azure VPNs:

Use Route-Based VPNs: They’re more flexible and support dynamic routing, which is a lifesaver for complex networks.
Monitor with Azure Monitor: Set up alerts for connection status changes. I’ve caught outages early thanks to this.
Document Everything: IP addresses, shared keys, and device configs—keep them in a secure vault like Azure Key Vault.
Test Redundancy: If uptime is critical, consider a dual-tunnel setup or ExpressRoute as a fallback.
Regularly Review NSGs and UDRs: A misconfigured rule can break your VPN silently.
Plan for Scalability: Start with VpnGw1, but be ready to scale up if your traffic grows.

Practice setting up a VPN in a lab environment. Use Azure’s free tier or a sandbox to avoid costs. The exam loves scenario-based questions, like “What happens if the Local Network Gateway’s IP is wrong?” (Spoiler: The connection fails.)

Conclusion

Setting up an Azure Site-to-Site VPN is like building a secure bridge between your on-premises world and the cloud. It’s not just about clicking through the portal—it’s about understanding how Azure’s networking components work together and anticipating where things might go wrong. Focus on the roles of the Virtual Network Gateway, Local Network Gateway, and Connection object, and be ready to troubleshoot common issues like mismatched settings or routing problems.

From my experience, the key to mastering this is practice and attention to detail. Set up a test VPN, break it, and fix it. That’s how you’ll build the confidence to handle real-world deployments and pass the exam with flying colors. Now go spin up that VPN and make your hybrid cloud dreams a reality.