Connect virtual networks from different deployment models using PowerShell
This article helps you 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 use PowerShell, but you can also create this configuration using the Azure portal 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
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.
- Both VNets have already been created. If you need to create a resource manager virtual network, see Create a resource group and a virtual network. To create a classic virtual network, see Create a classic VNet.
- 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.
You can use these values to create a test environment, or refer to them to better understand the examples in this article.
Classic VNet settings
VNet Name = ClassicVNet
Location = West US
Virtual Network Address Spaces = 10.0.0.0/24
Subnet-1 = 10.0.0.0/27
GatewaySubnet = 10.0.0.32/29
Local Network Name = RMVNetLocal
GatewayType = DynamicRouting
Resource Manager VNet settings
VNet Name = RMVNet
Resource Group = RG1
Virtual Network IP Address Spaces = 192.168.0.0/16
Subnet-1 = 192.168.1.0/24
GatewaySubnet = 192.168.0.0/26
Location = East US
Gateway public IP name = gwpip
Local Network Gateway = ClassicVNetLocal
Virtual Network Gateway name = RMGateway
Gateway IP addressing configuration = gwipconfig
Section 1 - Configure the classic VNet
1. Download your network configuration file
Log in to your Azure account in the PowerShell console with elevated rights. The following cmdlet prompts you for the login credentials for your Azure Account. After logging in, it downloads your account settings so that they are available to Azure PowerShell. The classic Service Management (SM) Azure PowerShell cmdlets are used in this section.
Get your Azure subscription.
If you have more than one subscription, select the subscription that you want to use.
Select-AzureSubscription -SubscriptionName "Name of subscription"
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
Open the .xml file that you downloaded to edit it. For an example of the network configuration file, see the Network Configuration Schema.
2. Verify the gateway subnet
In the VirtualNetworkSites element, add a gateway subnet to your VNet if one has not already been created. When working with the network configuration file, the gateway subnet MUST be named "GatewaySubnet" or Azure cannot recognize and use it as a gateway 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 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?
<VirtualNetworkSites> <VirtualNetworkSite name="ClassicVNet" Location="West US"> <AddressSpace> <AddressPrefix>10.0.0.0/24</AddressPrefix> </AddressSpace> <Subnets> <Subnet name="Subnet-1"> <AddressPrefix>10.0.0.0/27</AddressPrefix> </Subnet> <Subnet name="GatewaySubnet"> <AddressPrefix>10.0.0.32/29</AddressPrefix> </Subnet> </Subnets> </VirtualNetworkSite> </VirtualNetworkSites>
3. Add the local network site
The local network site you add represents the RM VNet to which you want to connect. Add a LocalNetworkSites element to the file if one doesn't already exist. At this point in the configuration, the VPNGatewayAddress can be any valid public IP address because we haven't yet created the gateway for the Resource Manager VNet. Once we create the gateway, we replace this placeholder IP address with the correct public IP address that has been assigned to the RM gateway.
<LocalNetworkSites> <LocalNetworkSite name="RMVNetLocal"> <AddressSpace> <AddressPrefix>192.168.0.0/16</AddressPrefix> </AddressSpace> <VPNGatewayAddress>22.214.171.124</VPNGatewayAddress> </LocalNetworkSite> </LocalNetworkSites>
4. Associate the VNet with the local network site
In this section, we specify the local network site that you want to connect the VNet to. In this case, it is the Resource Manager VNet that you referenced earlier. Make sure the names match. This step does not create a gateway. It specifies the local network that the gateway will connect to.
<Gateway> <ConnectionsToLocalNetwork> <LocalNetworkSiteRef name="RMVNetLocal"> <Connection type="IPsec" /> </LocalNetworkSiteRef> </ConnectionsToLocalNetwork> </Gateway>
5. Save the file and upload
Save the file, then import it to Azure by running the following command. Make sure you change the file path as necessary for your environment.
Set-AzureVNetConfig -ConfigurationPath C:\AzureNet\NetworkConfig.xml
You will see a similar result showing that the import succeeded.
OperationDescription OperationId OperationStatus -------------------- ----------- --------------- Set-AzureVNetConfig e0ee6e66-9167-cfa7-a746-7casb9 Succeeded
6. Create the gateway
Before running this example, refer to the network configuration file that you downloaded for the exact names that Azure expects to see. The network configuration file contains the values for your classic virtual networks. Sometimes the names for classic VNets 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, if you used the Azure portal to create a classic VNet named '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.
Use the following example to create a dynamic routing gateway:
New-AzureVNetGateway -VNetName ClassicVNet -GatewayType DynamicRouting
You can check the status of the gateway by using the Get-AzureVNetGateway cmdlet.
Section 2 - Configure the RM VNet gateway
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.
The prerequisites assume that you already have created an RM VNet. In this step, you create a VPN gateway for the RM VNet. Don't start these steps until after you have retrieved the public IP address for the classic VNet's gateway.
Sign in to your Azure account in the PowerShell console. The following cmdlet prompts you for the login credentials for your Azure Account. After signing in, your account settings are downloaded so that they are available to Azure PowerShell. You can optionally use the "Try It" feature to launch Azure Cloud Shell in the browser.
If you use Azure Cloud Shell, skip the following cmdlet:
To verify that you are using the right subscription, run the following cmdlet:
If you have more than one subscription, specify the subscription that you want to use.
Select-AzSubscription -SubscriptionName "Name of subscription"
Create a local network gateway. In a virtual network, the local network gateway typically refers to your on-premises location. In this case, the local network gateway refers to your Classic VNet. Give it a name by which Azure can refer to it, and also specify the address space prefix. Azure uses the IP address prefix you specify to identify which traffic to send to your on-premises location. If you need to adjust the information here later, before creating your gateway, you can modify the values and run the sample again.
-Name is the name you want to assign to refer to the local network gateway.
-AddressPrefix is the Address Space for your classic VNet.
-GatewayIpAddress is the public IP address of the classic VNet's gateway. Be sure to change the following sample text "n.n.n.n" to reflect the correct IP address.
New-AzLocalNetworkGateway -Name ClassicVNetLocal ` -Location "West US" -AddressPrefix "10.0.0.0/24" ` -GatewayIpAddress "n.n.n.n" -ResourceGroupName RG1
Request a public IP address to be allocated to the virtual network gateway for the Resource Manager VNet. You can't specify the IP address that you want to use. The IP address is dynamically allocated to the virtual network gateway. However, this does not mean the IP address changes. The only time the virtual network gateway IP address changes is when the gateway is deleted and recreated. It doesn't change across resizing, resetting, or other internal maintenance/upgrades of the gateway.
In this step, we also set a variable that is used in a later step.
$ipaddress = New-AzPublicIpAddress -Name gwpip ` -ResourceGroupName RG1 -Location 'EastUS' ` -AllocationMethod Dynamic
Verify that your virtual network has a gateway subnet. If no gateway subnet exists, add one. Make sure the gateway subnet is named GatewaySubnet.
Retrieve the subnet used for the gateway by running the following command. In this step, we also set a variable to be used in the next step.
-Name is the name of your Resource Manager VNet.
-ResourceGroupName is the resource group that the VNet is associated with. The gateway subnet must already exist for this VNet and must be named GatewaySubnet to work properly.
$subnet = Get-AzVirtualNetworkSubnetConfig -Name GatewaySubnet ` -VirtualNetwork (Get-AzVirtualNetwork -Name RMVNet -ResourceGroupName RG1)
Create the gateway IP addressing configuration. The gateway configuration defines the subnet and the public IP address to use. Use the following sample to create your gateway configuration.
In this step, the -SubnetId and -PublicIpAddressId parameters must be passed the id property from the subnet, and IP address objects, respectively. You can't use a simple string. These variables are set in the step to request a public IP and the step to retrieve the subnet.
$gwipconfig = New-AzVirtualNetworkGatewayIpConfig ` -Name gwipconfig -SubnetId $subnet.id ` -PublicIpAddressId $ipaddress.id
Create the Resource Manager virtual network gateway by running the following command. The
-VpnTypemust be RouteBased. It can take 45 minutes or more for the gateway to create.
New-AzVirtualNetworkGateway -Name RMGateway -ResourceGroupName RG1 ` -Location "EastUS" -GatewaySKU Standard -GatewayType Vpn ` -IpConfigurations $gwipconfig ` -EnableBgp $false -VpnType RouteBased
Copy the public IP address once the VPN gateway has been created. You use it when you configure the local network settings for your Classic VNet. You can use the following cmdlet to retrieve the public IP address. The public IP address is listed in the return as IpAddress.
Get-AzPublicIpAddress -Name gwpip -ResourceGroupName RG1
Section 3 - Modify the classic VNet local site settings
In this section, you work with the classic VNet. You replace the placeholder IP address that you used when specifying the local site settings that will be used to connect to the Resource Manager VNet gateway. Because you are working with the classic VNet, use PowerShell installed locally to your computer, not the Azure Cloud Shell TryIt.
Export the network configuration file.
Get-AzureVNetConfig -ExportToFile C:\AzureNet\NetworkConfig.xml
Using a text editor, modify the value for VPNGatewayAddress. Replace the placeholder IP address with the public IP address of the Resource Manager gateway and then save the changes.
Import the modified network configuration file to Azure.
Set-AzureVNetConfig -ConfigurationPath C:\AzureNet\NetworkConfig.xml
Section 4 - Create a connection between the gateways
Creating a connection between the gateways requires PowerShell. You may need to add your Azure Account to use the classic version of the PowerShell cmdlets. To do so, use Add-AzureAccount.
In the PowerShell console, set your shared key. Before running the cmdlets, refer to the network configuration file that you downloaded for the exact names that Azure expects to see. When specifying the name of a VNet that contains spaces, use single quotation marks around the value.
In following example, -VNetName is the name of the classic VNet and -LocalNetworkSiteName is the name you specified for the local network site. The -SharedKey is a value that you generate and specify. In the example, we used 'abc123', but you can generate and use 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. The return should show Status: Successful.
Set-AzureVNetGatewayKey -VNetName ClassicVNet ` -LocalNetworkSiteName RMVNetLocal -SharedKey abc123
Create the VPN connection by running the following commands:
Set the variables.
$vnet01gateway = Get-AzLocalNetworkGateway -Name ClassicVNetLocal -ResourceGroupName RG1 $vnet02gateway = Get-AzVirtualNetworkGateway -Name RMGateway -ResourceGroupName RG1
Create the connection. Notice that the -ConnectionType is IPsec, not Vnet2Vnet.
New-AzVirtualNetworkGatewayConnection -Name RM-Classic -ResourceGroupName RG1 ` -Location "East US" -VirtualNetworkGateway1 ` $vnet02gateway -LocalNetworkGateway2 ` $vnet01gateway -ConnectionType IPsec -RoutingWeight 10 -SharedKey 'abc123'
Section 5 - Verify your connections
To verify the connection from your classic VNet to your Resource Manager VNet
You can verify that your connection succeeded by using the 'Get-AzureVNetConnection' cmdlet.
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"
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
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
You can verify that your connection succeeded by using the 'Get-AzVirtualNetworkGatewayConnection' cmdlet, with or without '-Debug'.
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 want to test.
Get-AzVirtualNetworkGatewayConnection -Name VNet1toSite1 -ResourceGroupName TestRG1
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.
"connectionStatus": "Connected", "ingressBytesTransferred": 33509044, "egressBytesTransferred": 4142431
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.