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
- 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.
- Click Gateway in the Settings section of the menu, and then click on the banner 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 virtual network gateway
In this step, you create the virtual network gateway for your VNet. Creating a gateway can often take 45 minutes or more, depending on the selected gateway SKU.
The virtual network gateway uses specific subnet called the gateway subnet. The gateway subnet is part of the virtual network IP address range that you specify when configuring your virtual network. It contains the IP addresses that the virtual network gateway resources and services use.
When you create the gateway subnet, you specify the number of IP addresses that the subnet contains. The number of IP addresses needed depends on the VPN gateway configuration that you want to create. Some configurations require more IP addresses than others. We recommend that you create a gateway subnet that uses a /27 or /28.
If you see an error that specifies that the address space overlaps with a subnet, or that the subnet is not contained within the address space for your virtual network, check your VNet address range. You may not have enough IP addresses available in the address range you created for your virtual network. For example, if your default subnet encompasses the entire address range, there are no IP addresses left to create additional subnets. You can either adjust your subnets within the existing address space to free up IP addresses, or specify an additional address range and create the gateway subnet there.
- Virtual network gateway name = RMGateway
- Gateway type = VPN
- VPN type = Route-based
- SKU = VpnGw1
- Location = East US
- Virtual network = RMVNet
- GatewaySubnet = 192.168.0.0/26
- First IP configuration = rmgwpip
From the Azure portal menu, select Create a resource.
In the Search the Marketplace field, type 'Virtual Network Gateway'. Locate Virtual network gateway in the search return and select the entry. On the Virtual network gateway page, select Create. This opens the Create virtual network gateway page.
On the Basics tab, fill in the values for your virtual network gateway.
- Subscription: Select the subscription you want to use from the dropdown.
- Resource Group: This setting is autofilled when you select your virtual network on this page.
- Name: Name your gateway. Naming your gateway not the same as naming a gateway subnet. It's the name of the gateway object you are creating.
- Region: Select the region in which you want to create this resource. The region for the gateway must be the same as the virtual network.
- Gateway type: Select VPN. VPN gateways use the virtual network gateway type VPN.
- 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.
- Generation: For information about VPN Gateway Generation, see Gateway SKUs.
- Virtual network: From the dropdown, select the virtual network to which you want to add this gateway.
- Gateway subnet address range: This field only appears if your VNet doesn't have a gateway subnet. If possible, make the range /27 or larger (/26,/25 etc.). We don't recommend creating a range any smaller than /28. If you already have a gateway subnet, you can view GatewaySubnet details by navigating to your virtual network. Click Subnets to view the range. If you want to change the range, you can delete and recreate the GatewaySubnet.
Public IP address
This setting specifies the public IP address object that gets associated to the VPN gateway. The public IP address is dynamically assigned to this object when the VPN gateway is created. 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.
- Public IP address: Leave Create new selected.
- Public IP address name: In the text box, type a name for your public IP address instance.
- Assignment: VPN gateway supports only Dynamic.
Active-Active mode: Only select Enable active-active mode if you are creating an active-active gateway configuration. Otherwise, leave this setting Disabled.
Leave Configure BGP ASN as Disabled, unless your configuration specifically requires this setting. If you do require this setting, the default ASN is 65515, although this can be changed.
Select Review + create to run validation.
Once validation passes, select Create to deploy the VPN gateway. A gateway can take up to 45 minutes to fully create and deploy. You can see the deployment status on the Overview page for your gateway.
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 appears as a connected device.
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 Virtual Network gateway(VPN, Express Route gateway) to stop functioning as expected. For more information about network security groups, see What is a network security group?
3. 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, click +Create a resource.
In the search box, type Local network gateway, then press Enter to search. This will return a list of results. Click Local network gateway, then click the Create button 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.
- Endpoint: Select the endpoint type for the on-premises VPN device - IP address or FQDN (Fully Qualified Domain Name).
- IP address: If you have a static public IP address allocated from your Internet service provider for your VPN device, select the IP address option and fill in the IP address as shown in the example. This is the public IP address of the VPN device that you want Azure VPN gateway to connect to. If you don't have the IP address right now, you can use the values shown in the example, but you'll need to go back and replace your placeholder IP address with the public IP address of your VPN device. Otherwise, Azure will not be able to connect.
- FQDN: If you have a dynamic public IP address that could change after certain period of time, usually determined by your Internet service provider, you can use a constant DNS name with a Dynamic DNS service to point to your current public IP address of your VPN device. Your Azure VPN gateway will resolve the FQDN to determine the public IP address to connect to. A screenshot below shows an example of using FQDN instead of IP address.
- 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. Azure will route the address range that you specify to the on-premises VPN device IP address. Use your own values here if you want to connect to your on-premises site, not the values shown in the example.
- 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.
This is the same page, but with FQDN highlighted:
- Azure VPN supports only one IPv4 address for each FQDN. If the domain name resolves to multiple IP addresses, Azure VPN Gateway will use the first IP address returned by the DNS servers. To eliminate the uncertainty, it is recommended your FQDN always resolve to a single IPv4 address. IPv6 is not supported.
- Azure VPN Gateway maintains a DNS cache refreshed every 5 minutes. The gateway tries to resolve the FQDNs for disconnected tunnels only. Resetting the gateway will also trigger FQDN resolution.
When you have finished specifying the values, select the Create button to create the 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 (VNet).
On the virtual network page, select the type of connection that you want to see. For example, Site-to-site connections.
On the Site-to-site connections page, under Name, select the site connection you want to view.
On the Properties page, view the information about the connection.
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. In Essentials, you can view more information about your connection. The Status values are '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.