Pythian Blog: Technical Track

VPN Options with Azure: Azure to Site

by Pythian Marketing on Jul 26, 2020 12: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 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 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: Active-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: Site-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.
  4. Go back up to the Local network gateway option and select Choose a local network gateway.
  5. Select Create new, which opens the Create local network gateway blade.
  6. 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.
  7. Click OK to save the options and go back to the Add connection blade.
  8. 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 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: IKE 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: IKEv2 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).
  8. Go to the Advanced tab.
    1. Leave Enable Keep Alive enabled.
    2. Enable the Do not send trigger packet during IKE SA negotiation option.
  9. 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: 128 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.
  6. 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.
  7. Click OK to create the route.
  8. 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.
  9. 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.
  10. Locate the network interface configuration for the pfSense VM.
  11. Go to IP configurations under Settings.
  12. 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.

No Comments Yet

Let us know what you think

See all

See all

Subscribe by email
Follow us
Love Your Data
Pythian Logo

© 2024 All rights reserved.