Connect virtual networks from different deployment models using the portal
This article shows you how to connect classic VNets to Resource Manager VNets to allow the resources located in the separate deployment models to communicate with each other. The steps in this article primarily use the Azure portal, but you can also create this configuration using the PowerShell by selecting the article from this list.
Connecting a classic VNet to a Resource Manager VNet is similar to connecting a VNet to an on-premises site location. Both connectivity types use a VPN gateway to provide a secure tunnel using IPsec/IKE. 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 FAQ at the end of this article.
If you do not already have a virtual network gateway and do not want to create one, you may want to instead consider connecting your VNets using VNet Peering. VNet peering does not use a VPN gateway. For more information, see VNet peering.
Before you begin
This article has been updated to use the new Azure PowerShell Az module. You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. For Az module installation instructions, see Install Azure PowerShell.
- These steps assume that both VNets have already been created. If you are using this article as an exercise and don't have VNets, there are links in the steps to help you create them.
- Verify that 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.
- Install the latest PowerShell cmdlets for both Resource Manager and Service Management (classic). In this article, we use both the Azure portal and PowerShell. PowerShell is required to create the connection from the classic VNet to the Resource Manager VNet. For more information, see How to install and configure Azure PowerShell.
You can use these values to create a test environment, or refer to them to better understand the examples in this article.
VNet name = ClassicVNet
Address space = 10.0.0.0/24
Subnet name = Subnet-1
Subnet address range = 10.0.0.0/27
Subscription = the subscription you want to use
Resource Group = ClassicRG
Location = West US
GatewaySubnet = 10.0.0.32/28
Local site = RMVNetLocal
Resource Manager VNet
VNet name = RMVNet
Address space = 192.168.0.0/16
Resource Group = RG1
Location = East US
Subnet name = Subnet-1
Address range = 192.168.1.0/24
GatewaySubnet = 192.168.0.0/26
Virtual network gateway name = RMGateway
Gateway type = VPN
VPN type = Route-based
SKU = VpnGw1
Location = East US
Virtual network = RMVNet
(associate the VPN gateway to this VNet) First IP configuration = rmgwpip
(gateway public IP address) Local network gateway = ClassicVNetLocal
Connection name = RMtoClassic
For this configuration, you create a VPN gateway connection over an IPsec/IKE VPN tunnel between the virtual networks. Make sure that none of your VNet ranges overlap with each other, or with any of the local networks that they connect to.
The following table shows an example of how the example VNets and local sites are defined:
|Virtual Network||Address Space||Region||Connects to local network site|
|ClassicVNet||(10.0.0.0/24)||West US||RMVNetLocal (192.168.0.0/16)|
|RMVNet||(192.168.0.0/16)||East US||ClassicVNetLocal (10.0.0.0/24)|
Section 1 - Configure the classic VNet settings
In this section, you create the classic VNet, the local network (local site), and the virtual network gateway. Screenshots are provided as examples. Be sure to replace the values with your own, or use the Example values.
If you already have a VNet with a VPN gateway, verify that the gateway is Dynamic. If it's Static, you must first delete the VPN gateway before you proceed to Configure the local site.
- Open the Azure portal and sign in with your Azure account.
- Click + Create a resource to open the 'New' page.
- In the 'Search the marketplace' field, type 'Virtual Network'. If you instead, select Networking -> Virtual Network, you will not get the option to create a classic VNet.
- Locate 'Virtual Network' from the returned list and click it to open the Virtual Network page.
- On the virtual network page, select 'Classic' to create a classic VNet. If you take the default here, you will wind up with a Resource Manager VNet instead.
- Navigate to All resources and locate the ClassicVNet in the list.
- On the Overview page, in the VPN connections section, click Gateway to create a gateway.
- On the New VPN Connection page, for Connection type, select Site-to-site.
- For Local site, click Configure required settings. This opens the Local site page.
- On the Local site page, create a name to refer to the Resource Manager VNet. For example, 'RMVNetLocal'.
- 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 are doing these steps as an exercise, or don't yet have a virtual network gateway for your Resource Manager VNet, you can make up a placeholder IP address. Make sure that the placeholder IP address uses a valid format. Later, you replace the placeholder IP address with the Public IP address of the Resource Manager virtual network gateway.
- 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 Resource Manager virtual network. In the example, we use 192.168.0.0/16, the address range for the RMVNet.
- Click OK to save the values and return to the New VPN Connection page.
3. Create the virtual network gateway
On the New VPN Connection page, select the Create gateway immediately checkbox.
Click Optional gateway configuration to open the Gateway configuration page.
Click Subnet - Configure required settings to open the Add subnet page. The Name is already configured with the required value: GatewaySubnet.
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 IP addresses. This will accommodate future configurations that may require more available IP addresses. If possible, use /27 or /28. If you are using these steps as an exercise, you can refer to the Example values. For this example, we use '10.0.0.32/28'. Click OK to create the gateway subnet.
On the Gateway configuration page, Size refers to the gateway SKU. Select the gateway SKU for your VPN gateway.
Verify the Routing Type is Dynamic, then click OK to return to the New VPN Connection page.
On the New VPN Connection page, click OK to begin creating your VPN gateway. Creating a VPN gateway can take up to 45 minutes to complete.
4. Copy the virtual network gateway Public IP address
After the virtual network gateway has been created, you can view the gateway IP address.
- Navigate to your classic VNet, and click Overview.
- Click VPN connections to open the VPN connections page. On the VPN connections page, you can view the Public IP address. This is the Public IP address assigned to your virtual network gateway. Make a note of the IP address. You use it in later steps when you work with your Resource Manager local network gateway configuration settings.
- You can 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. You can close this page when you are finished viewing the status.
Section 2 - Configure the Resource Manager VNet settings
In this section, you create the virtual network gateway and the local network gateway for your Resource Manager VNet. Screenshots are provided as examples. Be sure to replace the values with your own, or use the Example values.
1. Create a virtual network
- VNet name = RMVNet
- Address space = 192.168.0.0/16
- Resource Group = RG1
- Location = East US
- Subnet name = Subnet-1
- Address range = 192.168.1.0/24
If you don't have a Resource Manager VNet and are running these steps as an exercise, create a virtual network with the steps in Create a virtual network, using the example values.
2. Create a gateway subnet
Example value: GatewaySubnet = 192.168.0.0/26
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.). If you are creating this as part of an exercise, you can use the Example values.
In the Azure portal, select the Resource Manager virtual network for which you want to create a virtual network gateway.
In the Settings section of your virtual network page, select Subnets to expand the Subnets page.
On the Subnets page, select Gateway subnet to open the Add subnet page.
The Name for your subnet is automatically autofilled with the value GatewaySubnet. This value is required for Azure to recognize the subnet as the gateway subnet. Adjust the autofilled Address range values to match your configuration requirements, then select OK to create the subnet.
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?
3. Create a virtual network gateway
- Virtual network gateway name = RMGateway
- Gateway type = VPN
- VPN type = Route-based
- SKU = VpnGw1
- Location = East US
- Virtual network = RMVNet
- First IP configuration = rmgwpip
Sign in to the Azure portal and select Create a resource. The New page opens.
In the Search the marketplace field, enter virtual network gateway, and select Virtual network gateway from the search list.
On the Virtual network gateway page, select Create to open the Create virtual network gateway page.
On the Create virtual network gateway page, fill in the values for your virtual network gateway:
Name: Enter a name for the gateway object you're creating. This name is different than the gateway subnet name.
Gateway type: Select VPN for VPN gateways.
VPN type: Select the VPN type that is specified for your configuration. Most configurations require a Route-based VPN type.
SKU: Select the gateway SKU from the dropdown. The SKUs listed in the dropdown depend on the VPN type you select. For more information about gateway SKUs, see Gateway SKUs.
Only select Enable active-active mode if you're creating an active-active gateway configuration. Otherwise, leave this setting unselected.
Location: You may need to scroll to see Location. Set Location to the location where your virtual network is located. For example, West US. If you don't set the location to the region where your virtual network is located, it won't appear in the drop-down list when you select a virtual network.
Virtual network: Choose the virtual network to which you want to add this gateway. Select Virtual network to open the Choose virtual network page and select the VNet. If you don't see your VNet, make sure the Location field is set to the region in which your virtual network is located.
Gateway subnet address range: You'll only see this setting if you didn't previously create a gateway subnet for your virtual network. If you previously created a valid gateway subnet, this setting won't appear.
Public IP address: This setting specifies the public IP address object that's associated with the VPN gateway. The public IP address is dynamically assigned to this object when the VPN gateway is created. The VPN gateway currently supports only Dynamic public IP address allocation. However, dynamic allocation doesn't mean that the IP address changes after it has been assigned to your VPN gateway. The only time the public IP address changes is when the gateway is deleted and re-created. It doesn't change across resizing, resetting, or other internal maintenance/upgrades of your VPN gateway.
Leave Create new selected.
In the text box, enter a name for your public IP address.
Configure BGP ASN: Leave this setting unselected, unless your configuration specifically requires it. If you do require this setting, the default ASN is 65515, which you can change.
Verify the settings and select Create to begin creating the VPN gateway. The settings are 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.
After you create the gateway, verify the IP address that's been assigned to it by viewing the virtual network in the portal. The gateway appears as a connected device. You can select the connected device (your virtual network gateway) to view more information.
4. Create a local network gateway
Example values: Local network gateway = ClassicVNetLocal
|Virtual Network||Address Space||Region||Connects to local network site||Gateway Public IP address|
|ClassicVNet||(10.0.0.0/24)||West US||RMVNetLocal (192.168.0.0/16)||The Public IP address that is assigned to the ClassicVNet gateway|
|RMVNet||(192.168.0.0/16)||East US||ClassicVNetLocal (10.0.0.0/24)||The Public IP address that is assigned to the RMVNet gateway.|
The local network gateway specifies the address range and the Public IP address associated with your classic VNet and its virtual network gateway. If you are doing these steps as an exercise, refer to the Example values.
In the portal, from All resources, click +Add.
In the Everything page search box, type Local network gateway, then click to return a list of resources. Click Local network gateway to open the page, then click Create to open the Create local network gateway page.
On the Create local network gateway page, specify the values for your local network gateway.
Name: Specify a name for your local network gateway object. If possible, use something intuitive, such as ClassicVNetLocal or TestVNet1Local. This makes it easier for you to identify the local network gateway in the portal.
IP address: 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: Specify 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: Specify the Public IP address that was assigned to the virtual network gateway for that VNet.
- If you don't yet have the IP address: You can make up a valid placeholder IP address, and then come back and modify this setting before connecting.
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 to which you connect.
Configure BGP settings: Use only when configuring BGP. Otherwise, don't select this.
Subscription: Verify that the correct subscription is showing.
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.
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.
Click Create to create the local network gateway.
Section 3 - Modify the classic VNet local site settings
In this section, you replace the placeholder IP address that you used when specifying the local site settings, with the Resource Manager VPN gateway IP address. This section uses the classic (SM) PowerShell cmdlets.
In the Azure portal, navigate to the classic virtual network.
On the page for your virtual network, click Overview.
In the VPN connections section, click the name of your local site in the graphic.
On the Site-to-site VPN connections page, click the name of the site.
On the connection page for your local site, click the name of the local site to open the Local site page.
On the Local site page, replace the VPN gateway IP address with the IP address of the Resource Manager gateway.
Click OK to update the IP address.
Section 4 - Create Resource Manager to classic connection
In these steps, you configure the connection from the Resource Manager VNet to the classic VNet using the Azure portal.
- In All resources, locate the local network gateway. In our example, the local network gateway is ClassicVNetLocal.
- Click Configuration and verify that the IP address value is the VPN gateway for the classic VNet. Update, if needed, then click Save. Close the page.
- In All resources, click the local network gateway.
- Click Connections to open the Connections page.
- On the Connections page, click + to add a connection.
- On the Add connection page, name the connection. For example, 'RMtoClassic'.
- Site-to-Site is already selected on this page.
- Select the virtual network gateway that you want to associate with this site.
- Create a shared key. This key is also used in the connection that you create from the classic VNet to the Resource Manager VNet. You can generate the key or make one up. In our example, we use 'abc123', but you can (and should) use something more complex.
- Click OK to create the connection.
Section 5 - Create classic to Resource Manager connection
In these steps, you configure the connection from the classic VNet to the Resource Manager VNet. These steps require PowerShell. You can't create this connection in the portal. Make sure you have downloaded and installed both the classic (SM) and Resource Manager (RM) PowerShell cmdlets.
1. Connect to your Azure account
Open the PowerShell console with elevated rights and log in to your Azure account. After logging in, your account settings are downloaded so that they are available to Azure PowerShell. The following cmdlet prompts you for the login credentials for your Azure Account for the Resource Manager deployment model:
Get a list of your Azure subscriptions.
If you have more than one subscription, specify the subscription that you want to use.
Select-AzSubscription -SubscriptionName "Name of subscription"
Next, log in to use the classic PowerShell cmdlets (Service Management). Use the following command to add your Azure account for the classic deployment model:
Get a list of your subscriptions. This step may be necessary when adding the Service Management cmdlets, depending on your Azure module install.
If you have more than one subscription, specify the subscription that you want to use.
Select-AzureSubscription -SubscriptionName "Name of subscription"
2. View the network configuration file values
When you create a VNet in the Azure portal, the full name that Azure uses is not visible in the Azure portal. For example, a VNet that appears to be named 'ClassicVNet' in the Azure portal may have a much longer name in the network configuration file. The name might look something like: 'Group ClassicRG ClassicVNet'. In these steps, you download the network configuration file and view the values.
Create a directory on your computer and then export the network configuration file to the directory. In this example, the network configuration file is exported to C:\AzureNet.
Get-AzureVNetConfig -ExportToFile C:\AzureNet\NetworkConfig.xml
Open the file with a text editor and view the name for your classic VNet. Use the names in the network configuration file when running your PowerShell cmdlets.
- VNet names are listed as VirtualNetworkSite name =
- Site names are listed as LocalNetworkSite name=
3. Create the connection
Set the shared key and create the connection from the classic VNet to the Resource Manager VNet. You cannot set the shared key using the portal. Make sure you run these steps while logged in using the classic version of the PowerShell cmdlets. To do so, use Add-AzureAccount. Otherwise, you will not be able to set the '-AzureVNetGatewayKey'.
- In this example, -VNetName is the name of the classic VNet as found in your network configuration file.
- The -LocalNetworkSiteName is the name you specified for the local site, as found in your network configuration file.
- 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 specified when creating your Resource Manager to classic connection.
Set-AzureVNetGatewayKey -VNetName "Group ClassicRG ClassicVNet" ` -LocalNetworkSiteName "172B9E16_RMVNetLocal" -SharedKey abc123
Section 6 - 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 changes from 'Connecting' to 'Connected'.
To verify the connection from your classic VNet to your Resource Manager VNet
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.
In the Azure portal, click All resources and navigate to your classic virtual network.
On the virtual network blade, click Overview to access the VPN connections section of the blade.
On the VPN connections graphic, click the site.
On the Site-to-site VPN connections blade, view the information about your site.
To view more information about the connection, click the name of the connection to open the Site-to-site VPN Connection blade.
To verify the connection from your Resource Manager VNet to your classic VNet
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.
In the Azure portal, click All resources and navigate to your virtual network gateway.
On the blade for your virtual network gateway, click Connections. You can see the status of each connection.
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.
The VNet-to-VNet FAQ applies to VPN gateway connections. For information about VNet peering, see Virtual network peering.
Does Azure charge for traffic between VNets?
VNet-to-VNet traffic within the same region is free for both directions when you use a VPN gateway connection. Cross-region VNet-to-VNet egress traffic is charged with the outbound inter-VNet data transfer rates based on the source regions. For more information, see VPN Gateway pricing page. If you're connecting your VNets by using VNet peering instead of a VPN gateway, see Virtual network pricing.
Does VNet-to-VNet traffic travel across the internet?
No. VNet-to-VNet traffic travels across the Microsoft Azure backbone, not the internet.
Can I establish a VNet-to-VNet connection across Azure Active Directory (AAD) tenants?
Yes, VNet-to-VNet connections that use Azure VPN gateways work across AAD tenants.
Is VNet-to-VNet traffic secure?
Yes, it's 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).
If the VNets aren't in the same subscription, do the subscriptions need to be associated with the same Active Directory tenant?
Can I use VNet-to-VNet to connect virtual networks in separate Azure instances?
No. VNet-to-VNet supports connecting virtual networks within the same Azure instance. For example, you can’t create a connection between global Azure and Chinese/German/US government Azure instances. Consider using a Site-to-Site VPN connection for these scenarios.
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 the 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 doesn't support connecting virtual machines or cloud services that aren't 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're connected together.
Can I use 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 use 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.