What You’ll Learn

What You’ll Need

Note: There is a cost for the VNet and associated VPN gateway within the Azure cloud. For testing and validation, the cost will be minimal, but ensure that you tear down the VPN after your testing is complete. Additionally, in this tutorial, a virtual Cisco Catalyst 8000 Series Router will be used. Configurations may need to be adjusted based on the router operating system and version.

The high-level architecture and terms to create this VPN connection are given below. Note that these terms are specific to Azure, and while similar constructs may exist within other cloud providers, they may not be called the same.

AWS VPN Diagram

Before any VPN connection can be established, the Azure VNet must be created. This VNet is similar to an Amazon Web Services (AWS) Virtual Private Cloud (VPC) and is the construct within Azure that contains an overarching supernet, which defines the address space for all compute and connection subnets within. The VNet is a representation of a logically segmented network, within which resources like compute instances, VPNs, or Kubernetes clusters can be instantiated. For this tutorial, we’ll simply use the VNet to create our VPN gateway separate from the rest of our cloud resources. In a production example, this VNet could be holding a variety of resources that would then be accessed over the VPN.

Creating the Azure VNet

To create the Azure VNet, log in to your Azure portal and search for virtual networks.

VNET search

From the Virtual networks management page, click the + Create icon on the left side of the window. This will bring up the virtual network creation window. You’ll be prompted with a new pane to create the VNet.

Note: In Azure, the “steps” or “tabs” around the creation pane look as though they are just part of the text, but they will highlight in light gray when moused over. The current pane will be bolded and have a blue underline. Additionally, at the bottom of every pane, you will see a “Review + create” button. It is important that you complete all required screens before clicking the Create button; otherwise, default settings (which may or may not be preferred) will be used.

On the Basics tab, you will be prompted for a virtual network name, region, and resource group. The resource group is a logical grouping of resources within Azure, and is similar to a tag or label. In a production environment, you may want to use an existing resource group; however, I have a created resource group that exists as part of my Azure subscription. The region is the Azure region in which the VNet will be created, and it should be geographically close to your current location. The name of the VNet can be anything you’d like, but it should be descriptive of the purpose of the VNet. In this example, we’ll use ENCC-VPN. When this is complete, click the Next button at the bottom of the screen.

New VNET creation

The Security pane will now be displayed. These settings aren’t required for this specific example, but they can (and should) be used when dealing with a production VNet.

VNET Security

The next step is to define the IPv4 address space for the VNet. By default, Azure will use the 10.0.0.0/16 space, which means that all subnets, compute, clusters, and other cloud constructs within this VNet will need to be assigned an address inside of that supernet. Additionally, Azure will create a default subnet of 10.0.0.0/24 to ensure that you have a starting point for your VNet. This subnet can be modified and edited using the pencil or trash can next to the subnet name.

VNET addresses

One thing of note is that if you change the supernet to be of a different scope (say, 10.1.0.0/16), Azure will not automatically update the default subnet to be within that new supernet. This is something that you will need to do manually, and you will receive a warning (with some hard-to-read text within) until this is updated. In this example, we’ll leave the supernet and subnet at the default values.

VNET default

Tags can be applied to the virtual network. Because this isn’t required, we will skip this step, at which point we are provided a “review” screen with our desired values. If everything is correct, we can click the Create button, and the virtual network will be created within our Azure tenant.

VNET create

Creating the VPN Gateway Subnet

Once the VNet is created, we need to create a unique VPN gateway subnet, which is unique from the default subnet created as part of the VNet instantiation. To do so, select the VNet, and then click Subnets under the Settings section of the VNet. This action will bring up a new pane, where you can click the + Gateway subnet button to create the new subnet. This subnet will be used to create the VPN gateway, and it will be assigned a public IP address that will be used to establish the VPN connection. You will need to enter just the desired network and mask (in Classless Inter-Domain Routing [CIDR] format; 10.0.1.0/24 is used in the following example). Each of the other options can be left at default (unchecked or None).

VNET gateway subnet

The next step is to create the Azure VNet gateway. This gateway is the construct within Azure that will be used to create the VPN connection to the on-premises router. This gateway will be created within the VNet that was created in the previous step and will be assigned a public IP address that will be used to establish the VPN connection.

Creating the Azure VNet Gateway

To create the gateway, search for virtual network gateways within the Azure portal, and click Create.

VGW create

This action will bring up a new activity pane to configure the parameters of the VPN gateway. You will need to provide a name for the gateway as well as the region that the resource will be configured in (which should match where your VNet is created). Ensure that the VPN radio button is selected so that this gateway will be used for VPNs rather than for an Azure ExpressRoute.

For the SKU, select VpnGw2. Each number appended at the end of “VpnGw” reflects the throughput or feature capabilities supported within the gateway. For our example, we could use VpnGw1 for low throughput, but it does not support Border Gateway Protocol (BGP) peering, so we need to use VpnGw2. Additionally, the appending of AZ allows you to choose the availability zone that the gateway is deployed in. We don’t necessarily care about this level of granularity, so we’ll use the “non-AZ” SKU.

We can leave the Generation at Generation2, and then we must select the desired virtual network to which we wish to attach the gateway. We will select the name of the VNet that we created in the previous step.

VGW settings part 1

By selecting the desired VNet, the Subnet value should auto-populate with the gateway subnet that we created in the previous step.

The remaining options reflect the connectivity and availability of the gateway. Ensure that the Create new radio box is selected for Public IP Address, and provide a name for this address to be identified within the Azure tenant.

We don’t necessarily care about high availability in this tutorial, so we’ll make sure that box is disabled.

We’ll peer with the gateway via BGP, so we’ll ensure that the Enabled radio button for Configure BGP is selected. Leave the Autonomous system number (ASN) at its default value, and don’t worry about the custom address box. Finally, click the Review + create button at the bottom of the screen to create the gateway.

VGW settings part 2

In similar fashion to AWS, we must also define the local device (our on-premises router/firewall/VPN endpoint) as a construct within the Azure cloud. This will provide some basic level of verification; the connection must come from this IP address. Also, because we’re working in the cloud, we must provide an endpoint to associate to the connection process. We do so by creating local network gateways within the Azure portal.

Creating the Local Network Gateway

To start creating the local gateway, search for local network gateways within the Azure portal.

LNG search

You’ll need to provide a name and region for the gateway. The name can be anything you’d like, but it should be descriptive of the purpose of the gateway. The region should be the same as the VNet and VPN gateway created in the previous steps.

The local device can be defined by either IP address or fully qualified domain name (FQDN). In this example, I have selected the IP address option, but you’ll need to replace the x.x.x.x with the external IP address of your network.

Under Address Space(s), you’ll need to define a network that will be used for the virtual tunnel interface (VTI) peering between the on-premises router and Azure. In the example, 192.168.150.0/30 is used.

LNG basic settings

Before creating the local gateway, the advanced settings will need to be configured. Click the Next: Advanced button at the bottom of the screen to bring up the Advanced settings pane. This pane is used to provide the local BGP configuration of the on-premises router. Ensure that Configure BGP Settings is set to Yes, and provide the ASN of your local router as well as the IP address that will be assigned to the VTI interface of your router. This IP address should be selected from the Address Space(s) list from the previous pane.

LNG BGP settings

Finally, review and create the local network gateway.

Now that the three major components within the Azure tenant have been created, we need to tie them together to support the VPN connection. This is done using the Connections service within Azure.

Building the VPN Connection

To begin creating a connection, search for connections within the Azure portal.

Connections search

Click the + Create button to bring up the connection creation wizard. The first window to appear will require you to configure a connection type, name, and region. The connection type should be Site-to-site (IPsec). The name can be anything you’d like, but it should be descriptive of the purpose of the connection, and the region should be the same as the VNet and VPN gateway created in the previous steps. When completed, click the Next: Settings > button at the bottom of the screen.

Connections basics

The next pane deals with the specific settings of the VPN connection itself. First, the Virtual network gateway and Local network gateway drop-down boxes should be filled with the constructs created in the previous steps. This associates the two disparate components with each other. Secondly, a pre-shared key (PSK) should be chosen. This setting differs from AWS in that Azure by default allows you to choose your desired key, whereas AWS will automatically generate a complex key for you; to choose your own key, you must override the setting.

Next, for this tutorial, we’ll use Internet Key Exchange version 2 (IKEv2) as the IKE protocol, ensure that we not use an Azure private IP address, and enable BGP within the configuration.

Connections settings part 1

We’ll now need to configure a custom IPsec/IKE policy for the VPN to ensure security. Start by selecting the Custom radio button, and then duplicate the following settings. These settings will ensure that the VPN connection is using modern ciphers and algorithms and will be compatible with the Cisco IOS XE router.

The rest of the settings can be left at their defaults.

Connections settings part 2

When completed, click the Review + create button at the bottom of the screen to review the settings and create the connection.

Before we can configure our local router, we need to gather two pieces of information from the Azure connections: the public IP address assigned to our VPN gateway and the IP address chosen by Azure for the remote end of the VTI tunnel.

To gather this information, go back to the VPN gateway that you created earlier; it should be listed under “Recent” on the home page of your Azure dashboard. Click Configuration on the left side of the window (under Settings). Toward the bottom of the configuration pane on the right side should be two rows of information: BGP peer IP address and Public IP Address. Ensure that you record those values to be implemented in the configuration template in the next step.

VPN info

In much the same way as AWS, the configuration for the VPN can be downloaded from the Azure portal. Go back to the connection that was created earlier (using “Recent” on the main dashboard page). At the top of the overview pane, click the Download configuration button to download the configuration template.

Download configuration

You will be required to input the device manufacturer, family, and software version.

Device template values

Modified Configuration

For a simplified configuration, you can download the configuration located here. This configuration distills a majority of what the Azure sample config provides as well as simplifies the repetitive config. The main points to replace are as follows:

Some assumptions are made for the fragmentation and maximum segment size (MSS) and maximum transmission unit (MTU). However, in this instance, even if large packets are sent, given that there is no traffic, the CPU load on the device (regardless of physical or virtual) should not be significant.

Once the configuration has been edited and applied to your edge device, the tunnels should connect to Azure. We can verify this using show crypto ikev2 sa [detail], a sample output of which is shown here:

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         192.168.128.92/4500   20.59.29.140/4500     none/none            READY
      Encr: AES-GCM, keysize: 256, PRF: SHA384, Hash: None, DH Grp:24, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/1240 sec
      CE id: 1461, Session-id: 460
      Local spi: 8C7AF7C06AC4C0C0       Remote spi: 16408DE9AF5973BE
      Status Description: Negotiation done
      Local id: <LOCAL-PUBLIC-IP>
      Remote id: 20.59.29.140
      Local req msg id:  7              Remote req msg id:  40
      Local next msg id: 7              Remote next msg id: 40
      Local req queued:  7              Remote req queued:  40
      Local window:      5              Remote window:      1
      DPD configured for 45 seconds, retry 2
      IETF Std Fragmentation  configured.
      Dynamic Route Update: disabled
      Extended Authentication not configured.
      NAT-T is detected inside
      Cisco Trust Security SGT is disabled
      Initiator of SA : Yes
      PEER TYPE: Other

Note that the encryption method, key size, Diffie-Helman group, and so on all align with the configuration that we applied to both the Azure and Cisco endpoints.

Once we can confirm that the IKEv2 security associations have been established, we can verify whether the IPsec security associations have formed as well. The command to view the output is show crypto ipsec sa [detail], and the output should look similar to the following:

interface: Tunnel1
    Crypto map tag: Tunnel1-head-0, local addr 192.168.128.92

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 20.59.29.140 port 4500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 83946, #pkts encrypt: 83946, #pkts digest: 83946
    #pkts decaps: 79085, #pkts decrypt: 79085, #pkts verify: 79085
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #pkts no sa (send) 0, #pkts invalid sa (rcv) 0
    #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
    #pkts invalid prot (recv) 0, #pkts verify failed: 0
    #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
    #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
    ##pkts replay failed (rcv): 0
    #pkts tagged (send): 0, #pkts untagged (rcv): 0
    #pkts not tagged (send): 0, #pkts not untagged (rcv): 0
    #pkts internal err (send): 0, #pkts internal err (recv) 0

     local crypto endpt.: 192.168.128.92, remote crypto endpt.: 20.59.29.140
     plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
     current outbound spi: 0x41937AE6(1100184294)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0xA0707DD9(2691726809)
        transform: esp-gcm 256 ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 2922, flow_id: CSR:922, sibling_flags FFFFFFFF80004048, crypto map: Tunnel1-head-0, initiator : True
         sa timing: remaining key lifetime (k/sec): (4607984/2296)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x41937AE6(1100184294)
        transform: esp-gcm 256 ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 2921, flow_id: CSR:921, sibling_flags FFFFFFFF80004048, crypto map: Tunnel1-head-0, initiator : True
         sa timing: remaining key lifetime (k/sec): (4607988/2296)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:

We also should validate the status of our BGP peering with Azure. This can be found by using the sh ip bgp summ command.

BGP router identifier 192.168.150.1, local AS number 65000
BGP table version is 1178, main routing table version 1178
3 network entries using 744 bytes of memory
3 path entries using 408 bytes of memory
2/2 BGP path/bestpath attribute entries using 592 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1768 total bytes of memory
BGP activity 201/198 prefixes, 590/587 paths, scan interval 60 secs
3 networks peaked at 16:25:07 Sep 20 2023 UTC (2w5d ago)

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.1.254      4        65515      29      30     1178    0    0 00:22:38        1

We have an active relationship with the Azure peer and are receiving the prefix from our supernet, as seen from sh ip route bgp.

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B        10.0.0.0/16 [20/0] via 10.0.1.254, 00:23:51

We can validate the status of the tunnels through the Azure dashboard for our site-to-site VPN connection. We can view this by selecting our VPN gateway from the dashboard. Check on the absolute status by selecting the VPN gateway, then clicking Connections under the Settings menu on the left side. This should indicate that the connection status is “Connected.”

VPN connection status

Additionally, by selecting Overview from the Virtual network gateway page, you can see the traffic statistics for the VPN connection over a selectable time period.

VPN taffic status

The VPN has now been configured!

Congratulations, you have successfully configured an IPsec VPN from an on-premises device to an Azure VPN gateway!

Learn More