# AZ - 700 - 02 - Design and implement hybrid networking

## **Hybrid Networking with Azure:** Connecting enterprise network to Azure

To build a secure and scalable hybrid network, start with VPNs. **Site-to-Site VPNs**, **Point-to-Site VPNs**, **Azure Virtual WAN** to connect and manage multiple sites or regions or **Network Virtual Appliances (NVAs)** for added security and routing control.

**Azure VPN Gateway** enables secure connections between your Azure environment and other locations. Before deploying a connection, you need a defined endpoint for the data—this is where the VPN Gateway setup begins.

We’ll briefly cover:

* **Types of connections** you can establish using the VPN Gateway
    
* **Configuration options** available for setup and deployment
    
* **Gateway generations and SKUs** to help you choose the best fit for your needs
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745515427572/6a6a9b5f-c962-4aea-85dc-93518a5bfa22.png align="center")

### **Azure VPN Gateway: Connection Types & Setup Essentials**

**Site-to-Site (S2S) VPN**

Connects an on-premises location to Azure. It can also link two Azure environments, though virtual network **peering** is more common now.

**Point-to-Site (P2S) VPN**

Allows individual devices—like laptops or phones—to securely connect to your Azure network using a VPN client or native Windows support.Perfect for remote work and on-the-go access.

**Setup Requirements**

Regardless of the connection type, you’ll need:

* A VPN Gateway in your Azure virtual network
    
* A public IP address for access
    
* Proper routing to allow traffic into your virtual network
    

### **Azure VPN Gateway: Planning, Provisioning & Connection Setup**

Before deploying a VPN Gateway in Azure, **planning is critical**. Start by creating a dedicated **gateway subnet** in your virtual network. You’ll need a **/27 or /28 CIDR block**, depending on your scaling needs. Only Azure-managed gateways (VPN and ExpressRoute) should use this subnet.

> **When you create your gateway subnet, gateway VMs are deployed to the gateway subnet and configured with the required VPN gateway settings.**

**Important:**

* One gateway per virtual network
    
* Never deploy non-gateway resources to the gateway subnet (e.g. no additional VMs)
    

Azure handles backend scaling automatically, ensuring your selected SKU meets bandwidth demands.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745519937844/a9b764a7-16e6-41d6-91f0-3864e47d3054.png align="center")

#### **Gateway Deployment Essentials**

To deploy a VPN gateway:

* Specify name, region, VPN type (Route-based or Policy-based), SKU, and generation
    
* Route-based (preferred) supports IKEv2 (آیک) and dynamic routing
    
* Policy-based supports only IKEv1 and is considered legacy
    
* Your choice of gateway SKU affects the number of connections and the aggregate throughput benchmark.
    
* Associate a virtual network that includes the gateway subnet.
    
* The gateway needs a public IP address.
    

Provisioning takes about **45 minutes**, so plan accordingly.

**Gateway SKU and Generation Comparison**:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745520101050/311e2e34-9e3f-4702-a2c1-2de72181cb3d.png align="center")

* *Gen1*: 650 Mbps–1.25 Gbps
    
* *Gen2*: Starts at 1.25 Gbps and scales higher
    
* You can resize within the same generation
    

The Basic SKU (not shown) is legacy and should not be used.

### **Site-to-Site VPN Setup**

A Site-to-Site (S2S) VPN allows you to establish a **secure connection over the public internet** between Azure and another location—whether that’s an on-premises data center, a private network, or even another cloud provider. This setup ensures that data remains protected while traversing public infrastructure.

To set this up, there are several steps involved, each addressing a piece of the connection:

**Typical Setup**:

* On the **Azure side**, you’ll have a **Virtual Network (VNet)** with subnets and a **VPN Gateway** already provisioned.
    
* On the **on-premises side**, your network (with resources like VMs) includes a **VPN-capable edge device**.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745520759510/5e134622-7b6b-4a61-a8d0-838198c66f90.png align="center")

The connection is made by **creating and linking resources** like the **local network gateway**, **VPN gateway**, and **VPN connection object** in Azure.

**Steps**:

1. **Create a local network gateway on azure** – A pointer resource in Azure that defines your on-prem location using a public IP or FQDN. Also specify the address space (e.g., 192.168.3.x) to configure proper routing.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745524836016/3b617e38-e3ec-4c25-a809-78192dfb20d0.png align="center")

2. **Configure the VPN device on-prem** – Use Microsoft’s prebuilt scripts for popular devices (Cisco, Ubiquiti, etc.). Generate and apply a shared key – Used for secure authentication.
    
3. **Create a VPN connection** – Link the **Azure VPN Gateway** with the **local network gateway** using the **shared key**.
    
    * **Create the connection object** after your VPN gateway is deployed and the on-prem device is configured.
        
    * **Name the connection** and set the type to **Site-to-site (IPSec)**.
        
    * **Select** both the **Azure VPN Gateway** and the **Local Network Gateway**.
        
    * **Enter the pre-shared key** used by the on-premises VPN device.
        

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745525814588/312ac270-45fd-4d71-8914-8752965913c5.png align="center")

4. always validate using **Network Watcher**, logs, and health probes to confirm connectivity and performance.
    
    * **Validate VPN throughput** to the VNet
        
    * **Utilize Network Watcher** for diagnostics
        
    * **Use diagnostic logs** to troubleshoot the Azure VPN Gateway
        
    * **Check UDR and NSGs** on the gateway subnet
        
    * **Verify the on-premises VPN device** is validated
        
    * **Verify shared key and VPN peer IPs**
        
    * **Use Azure gateway health probe** for status
        
    * **Check if the on-prem VPN device** supports perfect forward secrecy
        

So in summary:

* **Create a virtual network** with a **GatewaySubnet**.
    
* **Provision a Virtual Network Gateway** in that VNet.
    
* **Create a Local Network Gateway** with on-prem IP and address space.
    
* **Configure the on-prem VPN device** with matching settings.
    
* **Create the Site-to-Site VPN connection** using a shared key.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745531841891/848f5c79-c722-43d9-9df0-8f9b158c4a90.png align="center")

### **Point-to-Site VPN Setup**

Point-to-site (P2S) VPNs allow user devices (laptops, phones) to connect to Azure securely.

**Requirements**:

* Azure VPN Gateway already provisioned
    
* Proper **IP address pool** for connected users
    
* Compatible VPN clients (OpenVPN, SSTP, IKEv2)
    

**Authentication Options**:

* Azure Entra ID (formerly Azure AD)
    
* On-prem Active Directory via **RADIUS server**
    
* Choose based on identity store and protocol type
    

Configure in the Azure portal under **Point-to-site configuration**. Plan IP pool size based on expected simultaneous users.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745534366873/4cf1c63a-3746-4a0f-b5d1-596b53579559.png align="center")

### **Point-to-Site Configuration in Azure:**

To keep things smooth, no matter the **authentication method or connection type**, you need to go through the **initial setup** to ensure Point-to-Site works.

Head to your **Virtual Network Gateway**, scroll down, and click **Point-to-site configuration**. Here, configure key settings—especially the **address pool** for Point-to-Site connections. You’ll need a **subnet** with enough **private IPs** for each user connecting. Think about how many **simultaneous users** you’ll support—10, 100, 1,000, or more. Make sure there’s enough **IP space** to allow everyone to connect.

If you’re deploying **resilient options** like an **active-active gateway**, you’ll need **additional IPs** to support failover. Plan carefully—your **address range** and **number of IPs per user** will affect your setup. Once that’s done and **authentication is configured**, users can securely connect from anywhere.

In **Address pool**, enter the private IP range you want to assign to VPN clients. VPN clients will get IPs dynamically from this range. Use a **/29 subnet** for active/passive, **/28** for active/active setups.

### **VPN Gateway Resiliency Options**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745537454650/986fd143-f2f4-4a8d-bba4-335fc2d6cd1f.png align="center")

To ensure high availability:

**1.** Deploy virtual gateway in **Availability Zones** format(if region supports it):

e.g. We have **two gateway instances**, deployed in **separate availability zones**. These zones are **physically isolated**—with different power, cooling, and data centers—to ensure high uptime. All traffic can go to one location, but in case of a **failure or config issue**, it will **automatically fail over** to the other instance.

This setup ensures **high availability** and is one of the simplest ways to boost uptime.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745537738254/56a12cc3-3920-4307-8f6d-63fc9202851c.png align="center")

By default, gateways are in **active-standby mode**—only one connection is needed, and in case of failure, traffic shifts to the standby gateway. It’s easy to set up and works well for most cases.

**2\. Active-Active Configuration**:

Improves uptime by allowing multiple active paths. Requires extra on-prem setup and dual connections.

However, if **cutover downtime isn’t acceptable**, or you need **higher uptime**, choose the **active-active deployment**. This setup requires:

* Multiple connections on your side
    
* Following Azure’s **high availability architecture guidance**
    
* Planning for different **network topologies**
    

With active-active, your **VPN connection remains up** even if one side or gateway goes down. You’ll have **four possible paths**, so if one fails, others stay available.

### **Azure Virtual WAN Overview**

Azure Virtual WAN (vWAN) simplifies enterprise connectivity across regions, sites, and connection types.

**Benefits**:

* Centralized routing and policy management
    
* Supports **Site-to-Site, Point-to-Site**, and **ExpressRoute**
    
* Inter-region connectivity via linked hubs
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745538429831/1e26a1a7-f42b-4072-9c84-df6427e19536.png align="center")

### **Azure Virtual WAN Types & Capabilities**

* **Basic Virtual WAN / Hub**
    
    * Supports: Site-to-site VPN only
        
* **Standard Virtual WAN / Hub**
    
    * Supports:
        
        * ExpressRoute
            
        * User VPN (Point-to-site)
            
        * VPN (Site-to-site)
            
        * Inter-hub and VNet-to-VNet transiting through the virtual hub
            
    
    ### **Hub Private Address Space – Key Points**
    
    * **Minimum address space** required to create a hub is **/24**.
        
    * You **don’t need to manually plan subnets** for services in the virtual hub.(more flexible than vnet)
        
    * **Azure Virtual WAN is a managed service**—it automatically creates the necessary subnets for each gateway or service.
        
    * This includes services like:
        
        * VPN gateways
            
        * ExpressRoute gateways
            
        * User VPN (Point-to-site) gateways
            
        * Firewall, routing, etc.
            

**Deployment Steps**:

* Choose region, SKU (Basic or Standard), and private address space
    
* Standard SKU supports multi-region and all connection types
    
* Configure route tables for traffic flow between regions and branches
    

**Cross-tenant routing**: Azure Virtual WAN allows you to connect virtual networks from **other Azure tenants** into a **shared Virtual WAN hub**, enabling secure and centralized cross-tenant networking.

Whether you’re in a single-tenant or **multi-tenant** setup, it all comes down to one thing: **routing**—just like everything else in virtual networking.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745603017761/d447aa06-26d1-4c46-b7d3-8507b9c071e8.png align="center")

Just like in virtual networks, **Azure Virtual WAN** uses **route tables** to control traffic flow and define the **next hop**. In vWAN, you **propagate a route table at the hub**, which then gets automatically associated and pushed out to connected resources—so everything around the hub knows what’s inside it.

The **central hub** can handle up to **50 Gbps of aggregate throughput**, making it ideal for connecting multiple sites with high traffic demands.

By setting up route connections and defining paths in your **routing tables**, you control where traffic flows. Configuration is straightforward through the **default route table**, and for more advanced setups, click on the image below:

[![Diagram shows propagation.](https://learn.microsoft.com/en-us/azure/virtual-wan/media/about-virtual-hub-routing/concepts-propagation.png align="left")](https://learn.microsoft.com/en-us/azure/virtual-wan/about-virtual-hub-routing)

### **Deploying Network Virtual Appliances (NVAs) into a virtual hub:**

NVAs are third-party appliances like firewalls or SD-WAN tools deployed in Virtual WAN hubs. (Click on the image below for more info)

[![Process overview](https://learn.microsoft.com/en-us/azure/virtual-wan/media/about-nva-hub/high-level-process.png align="left")](https://learn.microsoft.com/en-us/azure/virtual-wan/about-virtual-hub-routing)

**Steps**:

1. **Choose from Azure Marketplace** – Vendors like Fortinet and VMware offer pre-configured solutions.
    
2. **Provision into Virtual WAN hub**
    
3. **Scale correctly** – Select the appropriate scale unit for required bandwidth
    
4. **Use vendor-provided tokens** for secure setup (Sometimes, the vendor requires you to provide an authentication token to verify that you’re a registered user. This must be obtained directly from the vendor.)
    

These are fully managed deployments, not manual VMs, and scale with your network needs.