---
title: "VPN Options with Azure: Azure to Site"
description: As business entities move some of their services to Microsoft Azure Cloud (Azure), we see hybrid networks emerge that can span multiple physical sites and
---

[Blog | Pythian ](https://www.pythian.com/blog)

# [VPN Options with Azure: Azure to Site](https://www.pythian.com/blog/vpn-options-with-azure-part-1-azure-to-site)

 Written by [Pythian](https://www.pythian.com/blog/author/pythian) | Jul 26, 2020 4:00:00 AM

As business entities move some of their services to **Microsoft Azure Cloud (Azure)**, we see hybrid networks emerge that can span multiple physical sites and multiple cloud environments. Connecting those network segments securely can present some challenges. I've encountered two types of client requests: Connect Azure to a remote site and connect Azure to another cloud environment. In this first part of our discussion, we'll cover the former, and two more common scenarios of a VPN tunnel between Azure and an existing remote site (on-premises) environment. We'll see specific details and a step-by-step guide for each option.

## Azure VPN Tunnel Options

 Azure provides several options to connect a remote site network to your cloud environment. For example, the site is remote from Azure's perspective and might be located in a data center or office.

- The Azure [ExpressRoute](https://docs.microsoft.com/en-us/azure/expressroute/expressroute-introduction) option requires private circuits to be already in place in the remote site. This type of connection has many benefits but can be expensive.
- The Azure VPN option uses the public Internet that has a lower cost and can still be secure. These VPNs can be either route-based or policy-based.

 Our focus will be on the Azure VPN options. The table below shows a general comparison between the two.

| **Route-based VPN** | **Policy-based VPN** |
| --- | --- |
| Encrypts all traversing traffic | Encrypts a subset of the traversing traffic according to a tunnel policy |
| Supports the exchange of dynamic routing information | Does not support the exchange of dynamic routing information |
| New network routes can be added as static or dynamically learned | New networks must be added to tunnel policy |
| Traversing traffic can be NAT'ed | Traversing traffic cannot be NAT'ed |
| Allow for load balancing and redundancy | Does not allow for load balancing and redundancy |
| Supports IKEv1 or IKEv2 | Supports IKEv1 only |

 

Additionally, IKEv2 provides [several advantages](http://rockhoppervpn.sourceforge.net/techdoc_ikev1vsikev2.html) over IKEv1 with an increasing number of network equipment supporting it. Considering the above, route-based IKEv2 VPN options are preferred where available, but I'll present a solution with a policy-based VPN when that is not the case.

## Site-to-Azure Route-based VPN Tunnel

 When the remote site gateway device supports route-based IKEv2 VPN, you can establish a standard connection to Azure. The next section covers the configuration in Azure and the remote site gateway.

## Azure VPN Tunnel Setup

 First, we'll go over a route-based IKEv2 VPN tunnel configuration of the Azure resources.

### Virtual Network Gateway

 In Azure, you need to create or already have in place at least one **Virtual Network Gateway (VNG)**. You can create multiple IKEv2 VPN tunnel connections under one VNG with one connection per remote location. Also, one VNG can serve the traffic only for a single Azure location, so you would need to create at least one VNG for each location that requires VPN tunnel connectivity. The following information describes how to create a VNG:

1. Search for "*virtual network gateways*" in the Azure console search bar.
2. Select **Virtual network gateways**.
3. Click **Add** in the upper left corner of the **Virtual network gateways** display.
4. Select or enter the following **Create virtual network gateway** options:  
     
     1. **Name:** A name for the VNG.
     2. **Region:** Azure Region where the VNG will be active.
     3. **Gateway type:** *VPN.*
     4. **VPN type:** *Route-based.*
     5. **SKU:** *VpnGw1.*
     6. **Virtual network:** The **Virtual Network (VNet)** will have access to the VPN tunnel. Use the *Create virtual network* option if the VNet doesn't already exist.
     7. **Gateway subnet address range:** Azure pre-fills the lowest available subnet from the chosen VNet. Use the zero subnet if available.
     8. **Public IP address:** *Create new* or *Use existing**.*
     9. **Public IP address name:** A name for the public IP address resource, if creating a new one.**Note**: **A****ctive-active mode** and **BGP ASN** are disabled, as our discussion is focused on the tunnel security options (and not on HA setup or dynamic routing exchange).
5. Proceed with creating the new VNG.**Note**: Deployment can take 20-30 minutes to complete.

### VPN Connection and Local Network Gateway

 Each Azure VPN tunnel is represented by a connection under its VNG. One VNG can service multiple tunnel connections. Unlike AWS, the public VPN gateway IP address in Azure is assigned to the gateway itself, as we saw in the VNG configuration discussed above. This is similar to a typical configuration in a physical VPN gateway device. The following steps show how to create a new connection and a local network gateway. The Local network gateway represents the remote network gateway and subnets, reachable through the tunnel.

1. Navigate to the VNG.
2. Select **Connections** and click the **Add** button.
3. Select or enter the following **Add connection** options:  
     
     1. **Name:** A name for the new connection.
     2. **Connection type:** *S**ite-to-site (IPsec).*
     3. **Virtual network gateway:** The parent VNG is already selected (locked in).
     4. **Shared key (PSK):** The PSK that matches on both sides fo the tunnel. This can be an arbitrary string and you can modify it later if this info is unavailable.
     5. **IKE Protocol:** *IKEv2*
     6. **Resource group:** The resource group is already locked in.

1. Go back up to the **Local network gateway** option and select **Choose a local network gateway**.
2. Select **Create new**, which opens the **Create local network gateway** blade.
3. Select or enter the following **Create local network gateway** options:  
     
     1. **Name:** A name for the local network gateway.
     2. **IP address:** The remote location gateway public IP address.
     3. **Address space:** The remote subnet.**Note**: Azure creates an internal static route for this subnet pointed at this VPN connection.
4. Click **OK** to save the options and go back to the **Add connection** blade.
5. Click **OK** to create the new connection.

### Remote Site VPN Tunnel Setup

 We'll configure a route-based IKEv2 VPN tunnel on the remote site gateway device to work with the newly created Azure VPN tunnel. Because we're working with the [default IPsec policies](https://docs.microsoft.com/en-us/azure/virtual-wan/virtual-wan-ipsec) on the Azure side, you must make any customization on the remote site gateway side. Those Azure defaults dictate the options chosen on the remote side. Our example below shows the setup in a physical SonicWall firewall device, but the configuration is similar on devices from other manufacturers.

### VPN Security Policy

 First, we'll create the VPN tunnel interface:

1. Navigate to the VPN -> **Settings** tab in the SonicWall GUI.
2. Click **Add** to create a new VPN policy. This takes you to the **General** tab.
3. Select or enter the following **Security Policy** options:  
     
     1. **Policy Type: ***Tunnel Interface.*
     2. **Authentication Method: **I*KE using Preshared Secret.*
     3. **Name:** Name for the tunnel.
     4. **IPsec Primary Gateway Name or Address:** The Azure VNG public IP address.
4. Select or enter the following **IKE Authentication** options:  
     
     1. **Shared Secret** and **Confirm Shared Secret: **Matching the Azure PSK.
     2. **Local IKE ID:** The SonicWall public IP address (with *IPv4 Address* selected)
     3. **Peer IKE ID:** The Azure VNG public IP address (with *IPv4 Address* selected)
5. Go to the **Proposals **tab.
6. Select or enter the following **IKE (Phase 1)** Proposal options:  
     
     1. **Exchange:** *I**KEv2 Mode.*
     2. **DH Group:** *Group 2.*
     3. **Encryption:** *AES-256.*
     4. **Authentication:** *SHA256.*
     5. **Life Time (seconds):** *1800.*
7. Select or enter the following **IPsec (Phase 2)** Proposal options:  
     
     1. **Protocol:** *ESP.*
     2. **Encryption:** *AES-256.*
     3. **Authentication:** *SHA256.*
     4. **Enable Perfect Forward Secrecy:** Enabled with **DH Group** set to *Group 14.*
     5. **Life Time (seconds):** *1800.*

**Note**: Phase 1 and 2 lifetime periods are much shorter than those default values on the Azure side (3600 seconds). This forces the Azure VNG to always be the responder during the negotiation stage which allows us to enable [**Perfect Forward Secrecy (PFS)**](https://weberblog.net/at-a-glance-perfect-forward-secrecy-pfs/)**.**

1. Go to the **Advanced **tab.  
     
     1. Leave **Enable Keep Alive** enabled.
     2. Enable the **Do not send trigger packet during IKE SA negotiation** option.
2. Click **OK** to save the configuration.

### Network Routing Policy

 Now, you can create the necessary static route for the Azure-bound traffic.

1. Navigate to the **Network-›****Routing** tab in the SonicWall GUI.
2. Click **Add** to create a new **Route Policy.**
3. Select the Azure network for **Destination. ** **Note**: Best practice is to use a network address object for the destination. You might need to create the object prior.
4. Set **Interface** to the VPN tunnel interface you just created.
5. Click **OK** to create the static route.

## Verification and Testing

 In the Azure VNG, verify that the VPN connection status under **Connections** is *Connected* *.* In the remote site gateway SonicWall device, go to **VPN **-> **Settings**. Under the **VPN Policies** section verify the Azure VPN tunnel shows in green. In the **Currently Active VPN Tunnels** section you can monitor the traffic passing through. If necessary, test connectivity between the systems on both sides of the VPN tunnel.

## Site-to-Azure policy-based IKEv1 VPN tunnel

 Some devices do not support route-based VPN tunnels, so one option is to create a new policy-based type Azure VNG to connect to those devices. However, because one Azure VNet can only connect to one VNG, this new VNG cannot connect directly to the needed VNet and additional peering and routing might be necessary. This could complicate the Azure configuration so a better solution might be to build a dedicated Azure VM that will act as a gateway. A VM running an IPsec application, such as **Netgate pfSense (pfSense)**, can act as a VPN gateway on the Azure side. The information below demonstrates how you can set up a pfSense application running in a VM as a gateway. You'll use a physical Meraki MX firewall device that doesn't support IKEv2 (IKEv2 is supported in the beta firmware version for some Meraki MX models). You can replicate this on devices from other manufacturers that do not support IKEv2. The setup on the Meraki side dictates the level of security configured on both sides.

## Azure VPN Tunnel Setup

#### Netgate pfSense VM

 First, you'll create a pfSense VM in Azure to serve as a VPN tunnel gateway. The following steps guide you through the setup:

1. Go to the Azure Marketplace and search for "*pfsense*" to find the **Netgate pfSense® Firewall/VPN/Router** app.
2. In the app, create a virtual appliance.
3. Create the VM, selecting resources (vCPU, RAM, and disk) as you would normally do in Azure.**Note**: You can use minimal values for these resources during this step. You can increase them later depending on the actual traffic load.
4. When choosing the **Networking** options, verify the network interface has the correct virtual network and subnet and that there is an assigned **Public IP** address:

### pfSense VPN configuration

1. When you create the VM and it's running, add a security rule in the VM **Networking configuration** to allow access from your public IP address on port 443.
2. Browse to the pfSense public IP address on port 443. Use the username chosen during the VM creation and the default password ***pfsense*** to log in.
3. When you are logged in, go to **System **-> **User Manager** and change the default password.
4. Go to **System **-> **Advanced **->** Firewall&NAT** and select the **Disable Firewall** option to disable all packet filtering. **Note**: pfSense can also act as a firewall in addition to the Azure security group configuration. Leave this option checked if your implementation requires it.
5. Go to **VPN** -> **IPsec **->** Tunnels** and select  to create phase 1 of the VPN tunnel.
6. Select or enter the following **General Information** options:  
     
     1. **Key Exchange version:** *IKEv1.*
     2. **Internet Protocol:** *IPv4.*
     3. **Interface:** *WAN.*
     4. **Remote Gateway:** The remote site gateway device public IP address.
     5. **Description:** A description for this VPN tunnel.
7. Select or enter the following **Phase 1 Proposal (Authentication)** options:  
     
     1. **Authentication Method:** *Mutual** PSK.*
     2. **Negotiation mode:** *Main.*
     3. **My identifier:** *My IP address.*
     4. **Peer identifier:** *Peer IP address.*
8. Click  under the **Pre-Shared Key** field to generate a random PSK.
9. Select or enter the following **Phase 1 Proposal (Encryption Algorithm)** options:  
     
     1. **Algorithm:** *AES.*
     2. **Key length:** *1**28 bits.*
     3. **Hash:** *SHA1.*
     4. **DH Group:** *5 (1536 bit).*
     5. **Lifetime (Seconds): ***14400. *
10. Click **Save** to finish setting up phase 1 of the VPN tunnel. This takes you back to the **VPN **->** IPsec **->** Tunnels** page.
11. Click  ->  to start the phase 2 VPN tunnel configuration.
12. Select or enter the following **General Information** options:  
      
      1. **Mode:** *Tunnel IPv4.*
      2. **Local Network** - **Type:** *Network. ***Address: **The Azure Vnet subnet.
      3. **NAT/BINAT translation:** *None.*
      4. **Remote Network** - **Type:** *Network.* **Address:** The remote site private subnet.
      5. **Description:** A description for this phase 2 tunnel.
13. Select or enter the following **Phase 2 Proposal (SA/Key Exchange)** options:  
      
      1. **Protocol:** *ESP.*
      2. **Encryption Algorithms:** *AES 256 bits.*
      3. **Hash Algorithms:** *SHA1.*
      4. **PFS key group:** *5 (1536 bit).*
      5. **Lifetime:** *3600.*
14. (Optional) In the **Advanced Configuration** section, you can use the **Automatically ping host** option as a keep-alive ICMP test.
15. Click **Save** to finish setting up this phase 2 VPN tunnel. This takes you back to the **VPN **->** IPsec **->** Tunnels** page.
16. To create additional phase 2 VPN tunnels, you can use the configuration of the recently created one as a template:
    
      1. Click  to show the phase 2 VPN tunnel you just created.
      2. Click the **copy** icon/button in the **P2 actions** column.
      3. Repeat steps 12 through 15 by only changing the necessary values.

### Route Table to pfSense VM

 Because the pfSense gateway is not a typical VNG, Azure would not have created an internal static route needed to handle the traffic bound towards the remote site network. You need to create a routing table with a static route for that purpose.

1. Search for "*route tables*" in the Azure console search bar.
2. Select **Route tables**.
3. Click **Add** in the upper left corner of the **Route tables** display.
4. Select or enter the following **Create route table** options:  
     
     1. **Name:** A name for the route table.
     2. **Resource group:** The same as the pfSense VM VNet.
     3. **Virtual network gateway route propagation: ***Enabled**. *
5. When it's created, go to **Settings **-> **Routes** and click **Add** to create a route.

1. Select or enter the following **Add route **options:  
     
     1. **Route name:** A name for the route.
     2. **Address prefix: **The subnet of the remote site.
     3. **Next hop type:** *Virtual appliance. *This opens the next option.
     4. **Next hop address: **The private IP address of the pfSense VM interface.**Note**: As seen from the warning, the VM receives traffic not destined for its IP address, which would be normally dropped. Enabling IP forwarding in the next steps remedies this situation.

1. Click **OK** to create the route.
2. Repeat steps 5 through 7 to create any additional routes under this route table for each subnet on the remote site that needs to be reachable over the VPN tunnel.
3. While still in the **Route table** view: 
     1. Go to **Settings **-> **Subnets** and click **Associate**.
     2. Select the VNet and subnet where the pfSense VM is located.
     3. Click **OK** to save the association.**Note**: As needed, you can add additional subnets here in your particular setup.
4. Locate the network interface configuration for the pfSense VM.
5. Go to **IP configurations** under **Settings**.
6. Enable the IP forwarding option.

### Remote Site VPN Tunnel Setup

 In the remote site gateway device, you'll configure a policy-based IKEv1 VPN tunnel to match settings implemented in the Azure pfSense VM. The following steps guide you through the setup:

### Meraki MX VPN Configuration

1. In the MX Security Appliance, go to **Security & SD-WAN-›****Configure **-> **Site-to-site VPN** -> **Non-Meraki VPN peers.**
2. Select *Hub (Mesh)* for **Type.**
3. Select the local subnets to include in the VPN tunnel policy.
4. Click **Add a peer**.
5. Enter a **Name,** following an established naming convention.
6. Specify the public IP of the Azure pfSense VM for **Public IP.**
7. Enter **Private subnets.** Those are all subnets on the Azure side that need to be reachable through the VPN tunnel.
8. Select the **Default** link under **IPsec policies**, which opens a new window to set custom policy.
9. Select or enter the following phase 1 options:  
     
     1. **Encryption: ***AES 128.*
     2. **Authentication: ***SHA1**.*
     3. **Diffie-Hellman group: ***5**.*
     4. **Lifetime (seconds): ***28800.*
10. Select or enter the following phase 2 options:  
      
      1. **Encryption: ***AES 256**.*
      2. **Authentication: ***SHA1.*
      3. **PFS group: ***5.*
      4. **Lifetime (seconds): ***7200.*
11. When your done customizing, click **Update**.
12. Enter the **Preshared secret.** You can retrieve the PSK by going back to **VPN **-> **IPsec **-> **Tunnels** of the pfSense GUI and editing the VPN tunnel. The PSK is in the **Phase 1 Proposal (Authentication)** section.
13. Leave** Availability** set to *All networks* unless there is a security requirement to limit the access to the VPN tunnel from particular subnets.
14. Click **Save** to complete the setup.

### Verification and Testing

 In the Azure pfSense GUI, go to **Status **-> **IPsec **-> **Overview** and verify the **Status** of the IPsec tunnel is  . Click  to show the phase 2 (child SA) tunnel's status and verify that they've also been established. **Note**: It's possible to have more than one child tunnel per remote subnet. In the remote site gateway Meraki device web UI, go to **Security appliance **-> **VPN** and click **Non-Meraki peer**. Verify the VPN tunnel has a status of "green." In the pfSense web UI, the **Diagnostics-›** **Ping** page provides a way to test with ping. If necessary, test connectivity between machines on both sides of the VPN tunnel. **Note**: If the VPN connection doesn't establish or is unstable, it might be necessary to change the security options (Encryption, Authentication, DH group, PFS) to less secure values. The same applies if the on-premises gateway device doesn't support the options used in the above examples.

## Conclusion

We covered two scenarios for a VPN connection from Azure to a remote site. With the increasing support for IKEv2, we'll see route-based VPN tunnels becoming the standard, and policy-based VPN connections the exception.

## Cloud Migrations

Ready to optimize your Oracle environment for the future?

[View full post](https://www.pythian.com/blog/vpn-options-with-azure-part-1-azure-to-site)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Pythian"
  },
  "dateModified" : "2026-01-19T17:43:58.254Z",
  "datePublished" : "2020-07-26T04:00:00Z",
  "headline" : "VPN Options with Azure: Azure to Site",
  "image" : {
    "@type" : "ImageObject",
    "height" : 60,
    "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
    "width" : 60
  },
  "mainEntityOfPage" : "https://www.pythian.com/blog/vpn-options-with-azure-part-1-azure-to-site",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60,
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
      "width" : 60
    },
    "name" : "Pythian Blog"
  }
}
```