Connect virtual networks from different deployment models using the portal

Azure currently has two management models: classic and Resource Manager (RM). If you have been using Azure for some time, you probably have Azure VMs and instance roles running in a classic VNet. Your newer VMs and role instances may be running in a VNet created in Resource Manager. This article walks you through connecting classic VNets to Resource Manager VNets to allow the resources located in the separate deployment models to communicate with each other over a gateway connection.

You can create a connection between VNets that are in different subscriptions and in different regions. You can also connect VNets that already have connections to on-premises networks, as long as the gateway that they have been configured with is dynamic or route-based. For more information about VNet-to-VNet connections, see the VNet-to-VNet considerations section at the end of this article.

Deployment models and methods for VNet-to-VNet connections

It's important to know that Azure currently works with two deployment models: Resource Manager and classic. Before you begin your configuration, make sure that you understand the deployment models and tools. You'll need to know which model that you want to work in. For information about the deployment models, see Understanding deployment models.

We update the following table as new articles and additional tools become available for this configuration. When an article is available, we link directly to it from the table.

VNet-to-VNet

Deployment Model/Method Azure Portal Classic Portal PowerShell
Classic Not Supported Article* Supported
Resource Manager Article+ Not Supported Article
Connections between different deployment models Article* Supported* Article

(+) denotes this deployment method is available only for VNets in the same subscription.
(*) denotes that this deployment method also requires PowerShell.

VNet peering

It's also possible to connect VNets without using a VPN gateway. If your VNets are in the same region, you may want to consider connecting them by using VNet peering. For more information, see the VNet peering article.

Before beginning

The following steps walk you through the settings necessary to configure a dynamic or route-based gateway for each VNet and create a VPN connection between the gateways. This configuration does not support static or policy-based gateways.

In this article, we will use the Azure portal and PowerShell. PowerShell is required to create the connections between the virtual networks. You cannot create the connections for this configuration by using the portal.

Prerequisites

  • Both VNets have already been created.
  • The address ranges for the VNets do not overlap with each other, or overlap with any of the ranges for other connections that the gateways may be connected to.
  • You have installed the latest PowerShell cmdlets. See How to install and configure Azure PowerShell for more information. Make sure you install both the Service Management (SM) and the Resource Manager (RM) cmdlets.

Example settings

You can use the example settings as reference.

Classic VNet settings

VNet Name = ClassicVNet
Address space = 10.0.0.0/24
Subnet-1 = 10.0.0.0/27
Resource Group = ClassicRG
Location = West US
GatewaySubnet = 10.0.0.32/28
Local site = RMVNetLocal

Resource Manager VNet settings

VNet Name = RMVNet
Address space = 192.168.0.0/16
Subnet-1 = 192.168.1.0/24
GatewaySubnet = 192.168.0.0/26
Resource Group = RG1
Location = East US
Virtual network gateway name = RMGateway
Gateway type = VPN
VPN type = Route-based
Gateway public IP name = gwpip
Local network gateway = ClassicVNetLocal

Section 1: Configure classic VNet settings

In this section, we will create the local network (local site) and the virtual network gateway for your classic VNet. The instructions in this section use the Azure portal. The steps here assume that a VPN gateway has not been created for the classic VNet. If you already have a gateway, verify that it is a Dynamic gateway. If it's Static, you must first delete the VPN gateway, then proceed with the following steps.

Part 1 - Configure the local site

Open the Azure portal and sign in with your Azure account.

  1. Navigate to All resources and locate the classic virtual network.
  2. On the Overview blade, in the VPN connections section, click the Gateway graphic to create a gateway.

    Configure a VPN gateway

  3. On the New VPN Connection blade, for Connection type, select Site-to-site.
  4. For Local site, click Configure required settings. This will open the Local site blade.
  5. On the Local site blade, create a name that you will use to refer to the Resource Manager VNet. For example, RMVNetLocal.
  6. If the VPN gateway for the Resource Manager VNet already has a public IP address, use the value for the VPN gateway IP address field. If you have not yet created a virtual network gateway for your Resource Manager VNet, you can use a placeholder IP address. Make sure that the placeholder IP address uses a valid format. Later, you must replace the placeholder IP address with the public IP address of the Resource Manager virtual network gateway.
  7. For Client Address Space, use the values for the virtual network IP address spaces for the Resource Manager VNet. This setting is used to specify the address spaces to route to the RM VNet.
  8. Click OK to save the values and return to the New VPN Connection blade.

Part 2 - Create the virtual network gateway

  1. On the New VPN Connection blade, select the Create gateway immediately checkbox and click Optional gateway configuration to open the Gateway configuration blade.

    Open gateway configuration blade

  2. Click Subnet - Configure required settings to open the Add subnet blade. On this blade, you'll see that the Name is already configured with the required value GatewaySubnet.
  3. The Address range refers to the range for the gateway subnet. Although you can create a gateway subnet with a /29 address range (3 addresses), we recommend creating a gateway subnet that contains more available IP addresses to accommodate possible future configurations that require more available IP addresses. If possible, use /27 or /28. Click OK to create the gateway subnet.
  4. On the Gateway configuration blade, Size refers to the gateway SKU. Select the gateway SKU for your VPN gateway.
  5. Verify the Routing Type is Dynamic, then click OK to return to the New VPN Connection blade.
  6. On the New VPN Connection blade, click OK to begin creating your VPN gateway. This can take up to 45 minutes to complete.

Part 3 - Copy the virtual network gateway public IP address

After the virtual network gateway has been created, you can view the gateway IP address.

  1. Navigate to your classic VNet, and click Overview.
  2. Click VPN connections to open the VPN connections blade. On the VPN connections blade, you can view the public IP address. This is the public IP address assigned to your virtual network gateway. Write down or copy the IP address. You will use it in later steps when you work with your Resource Manager local network gateway configuration settings. You can also view the status of your gateway connections. Notice the local network site you created is listed as 'Connecting'. The status will change after you have created your connections. Close the blade after copying the gateway IP address.

Section 2: Configure Resource Manager VNet settings

In this section, we will create the virtual network gateway and the local network for your Resource Manager VNet. Screenshots are provided as examples. Be sure to replace the values with your own. If you are creating this configuration as an exercise, refer to these values.

Part 1 - Create a gateway subnet

Before creating a virtual network gateway, you first need to create the gateway subnet. Create a gateway subnet with CIDR count of /28 or larger. (/27, /26, etc.)

Important

When working with gateway subnets, avoid associating a network security group (NSG) to the gateway subnet. Associating a network security group to this subnet may cause your VPN gateway to stop functioning as expected. For more information about network security groups, see What is a network security group?

From a browser, navigate to the Azure portal and sign in with your Azure account.

  1. In the portal, navigate to the Resource Manager virtual network for which you want to create a virtual network gateway.
  2. In the Settings section of your VNet blade, click Subnets to expand the Subnets blade.
  3. On the Subnets blade, click +Gateway subnet at the top. This will open the Add subnet blade.

    Add the gateway subnet

  4. The Name for your subnet will automatically be filled in with the value 'GatewaySubnet'. This value is required in order for Azure to recognize the subnet as the gateway subnet. Adjust the auto-filled Address range values to match your configuration requirements.

    Adding the subnet

  5. Click OK at the bottom of the blade to create the subnet.

Part 2 - Create a virtual network gateway

  1. In the portal, on the left side, click + and type "Virtual Network Gateway" in search. Locate Virtual network gateway in the search return and click the entry. On the Virtual network gateway blade, click Create at the bottom of the blade. This opens the Create virtual network gateway blade.
  2. On the Create virtual network gateway blade, fill in the values for your virtual network gateway.

    Create virtual network gateway blade fields

  3. Name: Name your gateway. This is not the same as naming a gateway subnet. It's the name of the gateway object you are creating.
  4. Gateway type: Select VPN. VPN gateways use the virtual network gateway type VPN.
  5. VPN type: Select the VPN type that is specified for your configuration. Most configurations require a Route-based VPN type.
  6. SKU: Select the gateway SKU from the dropdown. The SKUs listed in the dropdown depend on the VPN type you select.
  7. Location: Adjust the Location field to point to the location where your virtual network is located. If the location is not pointing to the region where your virtual network resides, the virtual network will not appear in the 'Choose a virtual network' dropdown.
  8. Choose the virtual network to which you want to add this gateway. Click Virtual network to open the Choose a virtual network blade. Select the VNet. If you don't see your VNet, make sure the Location field is pointing to the region in which your virtual network is located.
  9. Choose a public IP address. Click Public IP address to open the Choose public IP address blade. Click +Create New to open the Create public IP address blade. Input a name for your public IP address. This blade creates a public IP address object to which a public IP address will be dynamically assigned.
    Click OK to save your changes to this blade.
  10. Subscription: Verify that the correct subscription is selected.
  11. Resource group: This setting is determined by the Virtual Network that you select.
  12. Don't adjust the Location after you've specified the previous settings.
  13. Verify the settings. You can select Pin to dashboard at the bottom of the blade if you want your gateway to appear on the dashboard.
  14. Click Create to begin creating the gateway. The settings will be validated and you'll see the "Deploying Virtual network gateway" tile on the dashboard. Creating a gateway can take up to 45 minutes. You may need to refresh your portal page to see the completed status.

    Deploying Virtual network gateway

  15. After the gateway is created, you can view the IP address that has been assigned to it by looking at the virtual network in the portal. The gateway will appear as a connected device. You can click the connected device (your virtual network gateway) to view more information.

Creating a virtual network gateway can take up to 45 minutes. You can wait for the Resource Manager virtual network gateway creation to complete, or you can proceed to Part 3 - Create a local network gateway. Once the gateway has been created, it is assigned a public IP address. In later steps, this IP address is used to replace the placeholder IP address information for the classic VNet local site settings you created in Section 1.

Part 3 - Create a local network gateway

The local network gateway specifies the address range and the public IP address associated with your classic VNet and its virtual network gateway.

  • Use the public IP address that was assigned to your classic VNet gateway in the previous section.
  • Give the local network gateway a name by which Azure can refer to it. For example, 'ClassicVNetLocal'.
  • Use the address space that you assigned to your classic VNet (not just the subnet).
  1. In the portal, from All resources, click +Add. In the Everything blade search box, type Local network gateway, then click to search. This will return a list. Click Local network gateway to open the blade, then click Create to open the Create local network gateway blade.

    create local network gateway

  2. On the Create local network gateway blade, specify a Name for your local network gateway object.

  3. Specify a valid public IP address for the VPN device or virtual network gateway to which you want to connect.
    If this local network represents an on-premises location, this is the public IP address of the VPN device that you want to connect to. It cannot be behind NAT and has to be reachable by Azure.
    If this local network represents another VNet, you will specify the public IP address that was assigned to the virtual network gateway for that VNet.
  4. Address Space refers to the address ranges for the network that this local network represents. You can add multiple address space ranges. Make sure that the ranges you specify here do not overlap with ranges of other networks that you want to connect to.
  5. For Subscription, verify that the correct subscription is showing.
  6. For Resource Group, select the resource group that you want to use. You can either create a new resource group, or select one that you have already created.
  7. For Location, select the location that this object will be created in. You may want to select the same location that your VNet resides in, but you are not required to do so.
  8. Click Create to create the local network gateway.

Section 3: Modify the classic VNet local site settings

In this section, you will work with the classic VNet. You will replace the placeholder IP address that you used when specifying the local site settings. This section uses the classic (SM) PowerShell cmdlets. If you have not yet done so, view the virtual network gateway for the Resource Manager VNet and copy the public IP address. This is the IP address that you will use to replace the placeholder IP address.

Verify that you have downloaded the latest version of these cmdlets, as specified in the Before beginning section.

  1. In the Azure portal, navigate to the classic virtual network.
  2. On the blade for your virtual network, click Overview.
  3. In the VPN connections section, click the name of your local site in the graphic.

    VPN-connections

  4. On the Site-to-site VPN connections blade, click the name of the site.

    Site-name

  5. On the connection blade for your local site, click the name of the local site to open the Local site blade.

    Open-local-site

  6. On the Local site blade, replace the VPN gateway IP address with the IP address of the Resource Manager gateway.

    Gateway-ip-address

  7. Click OK to update the IP address.

Section 4: Create the connection

In this section, you will create the connection between the VNets. These steps require PowerShell. You can't create this connection in either of the portals. Make sure you have downloaded and installed both the classic (SM) and Resource Manager (RM) PowerShell cmdlets.

Part 1 - Log in to your Azure Account

  1. Open the PowerShell console with elevated rights and log in to your Azure account. The following cmdlet prompts you for the login credentials for your Azure Account. After logging in, your account settings are downloaded so that they are available to Azure PowerShell.

     Login-AzureRmAccount 
    
  2. Get a list of your Azure subscriptions if you have more than one subscription.

     Get-AzureRmSubscription
    
  3. Specify the subscription that you want to use.

     Select-AzureRmSubscription -SubscriptionName "Name of subscription"
    
  4. Add your Azure Account to use the classic PowerShell cmdlets. To do so, you can use the following command:

     Add-AzureAccount
    

Part 2 - Download your network configuration file

Sometimes the names for classic VNets and Local network sites are changed in the network configuration file when creating classic VNet settings in the Azure portal due to the differences in the deployment models. For example, using the Azure portal, we named the classic VNet 'Classic VNet' and created it in a resource group named 'ClassicRG'. The name that is contained in the network configuration file is converted to 'Group ClassicRG Classic VNet'. When specifying the name of a VNet that contains spaces, use quotation marks around the value.

  1. Export your Azure network configuration file by running the following command. You can change the location of the file to export to a different location if necessary.

     Get-AzureVNetConfig -ExportToFile C:\AzureNet\NetworkConfig.xml
    
  2. Use a text editor, such as Notepad, to open the .xml file and view the contents. Verify the values for the names of your classic virtual network and local network site.

Part 3 - Set the shared key

Set the shared key for the connection from the classic VNet to the Resource Manager VNet. When using these cmdlets, be sure to verify the values for -VNetName and -LocalNetworkSiteName using the network configuration file. When specifying names that contains spaces, use quotation marks around the value.

  • In this example, -VNetName is the name of the classic VNet.
  • -LocalNetworkSiteName is the name you specified for the local site.
  • The -SharedKey is a value that you generate and specify. For this example, we used abc123, but you can generate something more complex. The important thing is that the value you specify here must be the same value that you specify in the next step when you create your connection.

In the PowerShell console, set your shared key by running the following sample, making sure to replace the values with your own. The return for this sample should show Status: Successful.

    Set-AzureVNetGatewayKey -VNetName "Group ClassicRG ClassicVNet" `
    -LocalNetworkSiteName "172B9E16_RMVNetLocal" -SharedKey abc123

Part 4 - Create the VPN connection by running the following commands:

  1. Set the variables.

     $vnet01gateway = Get-AzureRMLocalNetworkGateway -Name ClassicVNetLocal -ResourceGroupName RG1
     $vnet02gateway = Get-AzureRmVirtualNetworkGateway -Name RMGateway -ResourceGroupName RG1
    
  2. Create the connection. In this example, -Name is the name that you want to name your connection, not something that you have already created. The following example creates a connection named 'RM-Classic'. Notice that the -ConnectionType is 'IPsec', not 'Vnet2Vnet', and that the -SharedKey matches the key you set earlier.

     New-AzureRmVirtualNetworkGatewayConnection -Name RM-Classic -ResourceGroupName RG1 `
     -Location "East US" -VirtualNetworkGateway1 `
     $vnet02gateway -LocalNetworkGateway2 `
     $vnet01gateway -ConnectionType IPsec -RoutingWeight 10 -SharedKey 'abc123'
    

Section 5: Verify your connections

You can verify your connections by using the Azure portal or PowerShell. When verifying, you may need to wait a minute or two as the connection is being created. When a connection is successful, the connectivity state will go from 'Connecting' to 'Connected'.

To verify the connection from your classic VNet to your Resource Manager VNet

Verify your connection using PowerShell

You can use the Get-AzureVNetConnection to verify the connection for a classic virtual network gateway.

  1. Use the following cmdlet example, configuring the values to match your own. The name of the virtual network must be in quotes if it contains spaces.

     Get-AzureVNetConnection "Group ClassicRG ClassicVNet"
    
  2. After the cmdlet has finished, view the values. In the example below, the Connectivity State shows as 'Connected' and you can see ingress and egress bytes.

     ConnectivityState         : Connected
     EgressBytesTransferred    : 181664
     IngressBytesTransferred   : 182080
     LastConnectionEstablished : 1/7/2016 12:40:54 AM
     LastEventID               : 24401
     LastEventMessage          : The connectivity state for the local network site 'RMVNetLocal' changed from Connecting to
                                 Connected.
     LastEventTimeStamp        : 1/7/2016 12:40:54 AM
     LocalNetworkSiteName      : RMVNetLocal
    

Verify your connection using the Azure Portal

In the Azure portal, you can view the connection status for a classic VNet VPN Gateway by navigating to the connection. The following steps show one way to navigate to your connection and verify.

  1. In the Azure portal, click All resources and navigate to your classic virtual network.
  2. On the virtual network blade, click Overview to access the VPN connections section of the blade.
  3. On the VPN connections graphic, click the site.

    Local site

  4. On the Site-to-site VPN connections blade, view the information about your site.

    Connection status

  5. To view more information about the connection, click the name of the connection to open the Site-to-site VPN Connection blade.

    Connection status more

To verify the connection from your Resource Manager VNet to your classic VNet

Verify your connection using PowerShell

You can verify that your connection succeeded by using the Get-AzureRmVirtualNetworkGatewayConnection cmdlet, with or without -Debug.

  1. Use the following cmdlet example, configuring the values to match your own. If prompted, select 'A' in order to run 'All'. In the example, -Name refers to the name of the connection that you created and want to test.

     Get-AzureRmVirtualNetworkGatewayConnection -Name MyGWConnection -ResourceGroupName MyRG
    
  2. After the cmdlet has finished, view the values. In the example below, the connection status shows as 'Connected' and you can see ingress and egress bytes.

     Body:
     {
       "name": "MyGWConnection",
       "id":
     "/subscriptions/086cfaa0-0d1d-4b1c-94544-f8e3da2a0c7789/resourceGroups/MyRG/providers/Microsoft.Network/connections/MyGWConnection",
       "properties": {
         "provisioningState": "Succeeded",
         "resourceGuid": "1c484f82-23ec-47e2-8cd8-231107450446b",
         "virtualNetworkGateway1": {
           "id":
     "/subscriptions/086cfaa0-0d1d-4b1c-94544-f8e3da2a0c7789/resourceGroups/MyRG/providers/Microsoft.Network/virtualNetworkGa
     teways/vnetgw1"
         },
         "localNetworkGateway2": {
           "id":
     "/subscriptions/086cfaa0-0d1d-4b1c-94544-f8e3da2a0c7789/resourceGroups/MyRG/providers/Microsoft.Network/localNetworkGate
     ways/LocalSite"
         },
         "connectionType": "IPsec",
         "routingWeight": 10,
         "sharedKey": "abc123",
         "connectionStatus": "Connected",
         "ingressBytesTransferred": 33509044,
         "egressBytesTransferred": 4142431
       }
    

Verify your connection using the Azure portal

In the Azure portal, you can view the connection status of a Resource Manager VPN Gateway by navigating to the connection. The following steps show one way to navigate to your connection and verify.

  1. In the Azure portal, click All resources and navigate to your virtual network gateway.
  2. On the blade for your virtual network gateway, click Connections. You can see the status of each connection.
  3. Click the name of the connection that you want to verify to open Essentials. In Essentials, you can view more information about your connection. The Status is 'Succeeded' and 'Connected' when you have made a successful connection.

    Verify VPN Gateway connection using Azure portal

VNet-to-VNet considerations

Does Azure charge for traffic between VNets?

VNet-to-VNet traffic within the same region is free for both directions. Cross region VNet-to-VNet egress traffic is charged with the outbound inter-VNet data transfer rates based on the source regions. Refer to the pricing page for details.

Does VNet-to-VNet traffic travel across the Internet?

No. VNet-to-VNet traffic travels across the Microsoft Azure backbone, not the Internet.

Is VNet-to-VNet traffic secure?

Yes, it is protected by IPsec/IKE encryption.

Do I need a VPN device to connect VNets together?

No. Connecting multiple Azure virtual networks together doesn't require a VPN device unless cross-premises connectivity is required.

Do my VNets need to be in the same region?

No. The virtual networks can be in the same or different Azure regions (locations).

Can I use VNet-to-VNet along with multi-site connections?

Yes. Virtual network connectivity can be used simultaneously with multi-site VPNs.

How many on-premises sites and virtual networks can one virtual network connect to?

See Gateway requirements table.

Can I use VNet-to-VNet to connect VMs or cloud services outside of a VNet?

No. VNet-to-VNet supports connecting virtual networks. It does not support connecting virtual machines or cloud services that are not in a virtual network.

Can a cloud service or a load balancing endpoint span VNets?

No. A cloud service or a load balancing endpoint can't span across virtual networks, even if they are connected together.

Can I used a PolicyBased VPN type for VNet-to-VNet or Multi-Site connections?

No. VNet-to-VNet and Multi-Site connections require Azure VPN gateways with RouteBased (previously called Dynamic Routing) VPN types.

Can I connect a VNet with a RouteBased VPN Type to another VNet with a PolicyBased VPN type?

No, both virtual networks MUST be using route-based (previously called Dynamic Routing) VPNs.

Do VPN tunnels share bandwidth?

Yes. All VPN tunnels of the virtual network share the available bandwidth on the Azure VPN gateway and the same VPN gateway uptime SLA in Azure.

Are redundant tunnels supported?

Redundant tunnels between a pair of virtual networks are supported when one virtual network gateway is configured as active-active.

Can I have overlapping address spaces for VNet-to-VNet configurations?

No. You can't have overlapping IP address ranges.

Can there be overlapping address spaces among connected virtual networks and on-premises local sites?

No. You can't have overlapping IP address ranges.