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 your VNets are in the same region, you may want to instead consider connecting them using VNet Peering. VNet peering does not use a VPN gateway. For more information, see VNet peering.
- 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-1 = 10.0.0.0/27
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
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 address name = rmgwpip
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)|
In this section, you create the local network (local site) and the virtual network gateway for your classic VNet. If you don't have a classic VNet and are running these steps as an exercise, you can create a VNet by using this article and the Example settings values from above. 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, then proceed.
Screenshots are provided as examples. Be sure to replace the values with your own, or use the Example values.
Part 1 - Configure the local site
Open the Azure portal and sign in with your Azure account.
- Navigate to All resources and locate the ClassicVNet in the list.
On the Overview blade, in the VPN connections section, click the Gateway graphic to create a gateway.
- On the New VPN Connection blade, for Connection type, select Site-to-site.
- For Local site, click Configure required settings. This opens the Local site blade.
- On the Local site blade, 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.
- Click OK to save the values and return to the New VPN Connection blade.
Part 2 - Create the virtual network gateway
On the New VPN Connection blade, select the Create gateway immediately checkbox and click Optional gateway configuration to open the Gateway configuration blade.
- Click Subnet - Configure required settings to open the Add subnet blade. 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. Click OK to create the gateway subnet.
- On the Gateway configuration blade, 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 blade.
- On the New VPN Connection blade, click OK to begin creating your VPN gateway. Creating a VPN gateway can take up to 45 minutes to complete.
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 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 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.
In this section, you create the virtual network gateway and the local network gateway for your Resource Manager VNet. If you don't have a Resource Manager VNet and are running these steps as an exercise, you can create a VNet by using this article and the Example settings values from above.
Screenshots are provided as examples. Be sure to replace the values with your own, or use the Example 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.)
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?
- In the portal, navigate to the Resource Manager virtual network for which you want to create a virtual network gateway.
- In the Settings section of your VNet blade, click Subnets to expand the Subnets blade.
On the Subnets blade, click +Gateway subnet to open the Add subnet blade.
The Name for your subnet is automatically 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.
- To create the subnet, click OK at the bottom of the blade.
Part 2 - Create a virtual network gateway
- 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.
On the Create virtual network gateway blade, fill in the values for your virtual network gateway.
- 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.
- 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.
- 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 doesn't appear in the 'Choose a virtual network' dropdown.
- 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.
- Public IP address: This blade creates a public IP address object to which a public IP address will be dynamically assigned. 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. Click OK to save your changes to this blade. The IP address is dynamically assigned when the VPN gateway is created. VPN Gateway currently only supports Dynamic Public IP address allocation. However, this does not 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.
- Subscription: Verify that the correct subscription is selected.
- Resource group: This setting is determined by the Virtual Network that you select.
- Don't adjust the Location after you've specified the previous settings.
- Verify the settings. If you want your gateway to appear on the dashboard, you can select Pin to dashboard at the bottom of the blade.
- Click Create to begin creating the gateway. The settings are validated and the gateway will deploy. Creating a gateway can take up to 45 minutes.
- 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. You can click the connected device (your virtual network gateway) to view more information.
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 these settings:
|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.|
In the portal, from All resources, click +Add. In the Everything blade search box, type Local network gateway, then click to return a list of resources. Click Local network gateway to open the blade, then click Create to open the Create local network gateway blade.
On the Create local network gateway blade, 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.
- 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.
- For Subscription, verify that the correct subscription is showing.
- 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.
- For Location, select the location in which this resource will be created. 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.
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 blade 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 blade, click the name of the site.
On the connection blade for your local site, click the name of the local site to open the Local site blade.
On the Local site blade, replace the VPN gateway IP address with the IP address of the Resource Manager gateway.
- Click OK to update the IP address.
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 blade.
- In All resources, click the local network gateway.
- Click Connections to open the Connections blade.
- On the Connections blade, click + to add a connection.
- On the Add connection blade, name the connection. For example, 'RMtoClassic'.
- Site-to-Site is already selected on this blade.
- 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.
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. 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.
Get a list of your Azure subscriptions if you have more than one subscription.
Specify the subscription that you want to use.
Select-AzureRmSubscription -SubscriptionName "Name of subscription"
Add your Azure Account to use the classic PowerShell cmdlets (SM). To do so, you can use the following command:
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
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.
Does Azure charge for traffic between VNets?
VNet-to-VNet traffic within the same region is free for both directions when using 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. Refer to the VPN Gateway pricing page for details. If you are connecting your VNets using VNet Peering, rather than VPN Gateway, see the Virtual Network pricing page.
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.