Hook yourself to CLOUD: Configure a VNet-to-VNet connection (classic)

Note

This article is written for the classic deployment model. If you're new to Azure, we recommend that you use the Resource Manager deployment model instead. The Resource Manager deployment model is the most current deployment model and offers more options and feature compatibility than the classic deployment model. For more information about the deployment models, see Understanding deployment models.

For the Resource Manager version of this article, select it from the drop-down list below, or from the table of contents on the left.

This article helps you create a VPN gateway connection between virtual networks. The virtual networks can be in the same or different regions, and from the same or different subscriptions. The steps in this article apply to the classic deployment model and the Azure portal. You can also create this configuration using a different deployment tool or deployment model by selecting a different option from the following list:

About VNet-to-VNet connections

Connecting a virtual network to another virtual network (VNet-to-VNet) in the classic deployment model using a VPN gateway is similar to connecting a virtual network to an on-premises site location. Both connectivity types use a VPN gateway to provide a secure tunnel using IPsec/IKE.

The VNets you connect can be in different subscriptions and different regions. You can combine VNet to VNet communication with multi-site configurations. This lets you establish network topologies that combine cross-premises connectivity with inter-virtual network connectivity.

Why connect virtual networks?

You may want to connect virtual networks for the following reasons:

Cross region geo-redundancy and geo-presence
- You can set up your own geo-replication or synchronization with secure connectivity without going over Internet-facing endpoints.
- With Azure Load Balancer and Microsoft or third-party clustering technology, you can set up highly available workload with geo-redundancy across multiple Azure regions. One important example is to set up SQL Always On with Availability Groups spreading across multiple Azure regions.
Regional multi-tier applications with strong isolation boundary
- Within the same region, you can set up multi-tier applications with multiple VNets connected together with strong isolation and secure inter-tier communication.
Cross subscription, inter-organization communication in Azure
- If you have multiple Azure subscriptions, you can connect workloads from different subscriptions together securely between virtual networks.
- For enterprises or service providers, you can enable cross-organization communication with secure VPN technology within Azure.

For more information about VNet-to-VNet connections, see VNet-to-VNet considerations at the end of this article.

Before you begin

Before beginning this exercise, download and install the latest version of the Azure Service Management (SM) PowerShell cmdlets. For more information, see How to install and configure Azure PowerShell. We use the portal for most of the steps, but you must use PowerShell to create the connections between the VNets. You can't create the connections using the Azure portal.

Step 1 - Plan your IP address ranges

It’s important to decide the ranges that you’ll use to configure your virtual networks. For this configuration, you must 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 to define your VNets. Use the ranges as a guideline only. Write down the ranges for your virtual networks. You need this information for later steps.

Example

Virtual Network	Address Space	Region	Connects to local network site
TestVNet1	TestVNet1 (10.11.0.0/16) (10.12.0.0/16)	East US	VNet4Local (10.41.0.0/16) (10.42.0.0/16)
TestVNet4	TestVNet4 (10.41.0.0/16) (10.42.0.0/16)	West US	VNet1Local (10.11.0.0/16) (10.12.0.0/16)

Step 2 - Create the virtual networks

Create two virtual networks in the Azure portal. For the steps to create classic virtual networks, see Create a classic virtual network.

When using the portal to create a classic virtual network, you must navigate to the virtual network page by using the following steps, otherwise the option to create a classic virtual network does not appear:

Click the '+' 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 are using this article as an exercise, you can use the following example values:

Values for TestVNet1

Name: TestVNet1
Address space: 10.11.0.0/16, 10.12.0.0/16 (optional)
Subnet name: default
Subnet address range: 10.11.0.1/24
Resource group: ClassicRG
Location: East US
GatewaySubnet: 10.11.1.0/27

Values for TestVNet4

Name: TestVNet4
Address space: 10.41.0.0/16, 10.42.0.0/16 (optional)
Subnet name: default
Subnet address range: 10.41.0.1/24
Resource group: ClassicRG
Location: West US
GatewaySubnet: 10.41.1.0/27

When creating your VNets, keep in mind the following settings:

Virtual Network Address Spaces – On the Virtual Network Address Spaces page, specify the address range that you want to use for your virtual network. These are the dynamic IP addresses that will be assigned to the VMs and other role instances that you deploy to this virtual network.
The address spaces you select cannot overlap with the address spaces for any of the other VNets or on-premises locations that this VNet will connect to.
Location – When you create a virtual network, you associate it with an Azure location (region). For example, if you want your VMs that are deployed to your virtual network to be physically located in West US, select that location. You can’t change the location associated with your virtual network after you create it.

After creating your VNets, you can add the following settings:

Address space – Additional address space is not required for this configuration, but you can add additional address space after creating the VNet.
Subnets – Additional subnets are not required for this configuration, but you might want to have your VMs in a subnet that is separate from your other role instances.
DNS servers – Enter the DNS server name and IP address. This setting does not create a DNS server. It allows you to specify the DNS servers that you want to use for name resolution for this virtual network.

In this section, you configure the connection type, the local site, and create the gateway.

Step 3 - Configure the local site

Azure uses the settings specified in each local network site to determine how to route traffic between the VNets. Each VNet must point to the respective local network that you want to route traffic to. You determine the name you want to use to refer to each local network site. It's best to use something descriptive.

For example, TestVNet1 connects to a local network site that you create named 'VNet4Local'. The settings for VNet4Local contain the address prefixes for TestVNet4.

The local site for each VNet is the other VNet. The following example values are used for our configuration:

Virtual Network	Address Space	Region	Connects to local network site
TestVNet1	TestVNet1 (10.11.0.0/16) (10.12.0.0/16)	East US	VNet4Local (10.41.0.0/16) (10.42.0.0/16)
TestVNet4	TestVNet4 (10.41.0.0/16) (10.42.0.0/16)	West US	VNet1Local (10.11.0.0/16) (10.12.0.0/16)

Locate TestVNet1 in the Azure portal. In the VPN connections section of the page, click Gateway.
On the New VPN Connection page, select Site-to-Site.
Click Local site to open the Local site page and configure the settings.
On the Local site page, name your local site. In our example, we name the local site 'VNet4Local'.
For VPN gateway IP address, you can use any IP address that you want, as long as it's in a valid format. Typically, you’d use the actual external IP address for a VPN device. But, for a classic VNet-to-VNet configuration, you use the public IP address that is assigned to the gateway for your VNet. Given that you’ve not yet created the virtual network gateway, you specify any valid public IP address as a placeholder.
Don't leave this blank - it's not optional for this configuration. In a later step, you go back into these settings and configure them with the corresponding virtual network gateway IP addresses once Azure generates it.
For Client Address Space, use the address space of the other VNet. Refer to your planning example. Click OK to save your settings and return back to the New VPN Connection page.

Step 4 - Create the virtual network gateway

Each virtual network must have a virtual network gateway. The virtual network gateway routes and encrypts traffic.

On the New VPN Connection page, select the checkbox Create gateway immediately.
Click Subnet, size and routing type. On the Gateway configuration page, click Subnet.
The gateway subnet name is filled in automatically with the required name 'GatewaySubnet'. The Address rangecontains the IP addresses that are allocated to the VPN gateway services. Some configurations allow a gateway subnet of /29, but it's best to use a /28 or /27 to accommodate future configurations that may require more IP addresses for the gateway services. In our example settings, we use 10.11.1.0/27. Adjust the address space, then click OK.
Configure the Gateway Size. This setting refers to the Gateway SKU.
Configure the Routing Type. The routing type for this configuration must be Dynamic. You can't change the routing type later unless you tear down the gateway and create a new one.
Click OK.
On the New VPN Connection page, click OK to begin creating the virtual network gateway. Creating a gateway can often take 45 minutes or more, depending on the selected gateway SKU.

Step 5 - Configure TestVNet4 settings

Repeat the steps to Create a local site and Create the virtual network gateway to configure TestVNet4, substituting the values when necessary. If you are doing this as an exercise, use the Example values.

Step 6 - Update the local sites

After your virtual network gateways have been created for both VNets, you must adjust the local sites VPN gateway IP address values.

VNet name	Connected site	Gateway IP address
TestVNet1	VNet4Local	VPN gateway IP address for TestVNet4
TestVNet4	VNet1Local	VPN gateway IP address for TestVNet1

Part 1 - Get the virtual network gateway public IP address

Locate your virtual network in the Azure portal.
Click to open the VNet Overview page. On the page, in VPN connections, you can view the IP address for your virtual network gateway.
Copy the IP address. You will use it in the next section.
Repeat these steps for TestVNet4

Part 2 - Modify the local sites

Locate your virtual network in the Azure portal.
On the VNet Overview page, click the local site.
On the Site-to-Site VPN Connections page, click the name of the local site that you want to modify.
Click the Local site that you want to modify.
Update the VPN gateway IP address and click OK to save the settings.
Close the other pages.
Repeat these steps for TestVNet4.

Step 7 - Retrieve values from the network configuration file

When you create classic VNets in the Azure portal, the name that you view is not the full name that you use for PowerShell. For example, a VNet that appears to be named TestVNet1 in the portal, may have a much longer name in the network configuration file. The name might look something like: Group ClassicRG TestVNet1. When you create your connections, it's important to use the values that you see in the network configuration file.

In the following steps, you will connect to your Azure account and download and view the network configuration file to obtain the values that are required for your connections.

Download and install the latest version of the Azure Service Management (SM) PowerShell cmdlets. For more information, see How to install and configure Azure PowerShell.
Open your PowerShell console with elevated rights and connect to your account. Use the following example to help you connect:

PowerShell
```
Connect-AzureRmAccount
```
Check the subscriptions for the account.

PowerShell
```
Get-AzureRmSubscription
```
If you have more than one subscription, select the subscription that you want to use.

PowerShell
```
Select-AzureRmSubscription -SubscriptionName "Replace_with_your_subscription_name"
```
Next, use the following cmdlet to add your Azure subscription to PowerShell for the classic deployment model.

PowerShell
```
Add-AzureAccount
```
Export and view the network configuration file. 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.

PowerShell
```
Get-AzureVNetConfig -ExportToFile C:\AzureNet\NetworkConfig.xml
```
Open the file with a text editor and view the names for your VNets and sites. These will be the name you use when you create your connections.
VNet names are listed as VirtualNetworkSite name =
Site names are listed as LocalNetworkSiteRef name =

Step 8 - Create the VPN gateway connections

When all the previous steps have been completed, you can set the IPsec/IKE pre-shared keys and create the connection. This set of steps uses PowerShell. VNet-to-VNet connections for the classic deployment model cannot be configured in the Azure portal.

In the examples, notice that the shared key is exactly the same. The shared key must always match. Be sure to replace the values in these examples with the exact names for your VNets and Local Network Sites.

Create the TestVNet1 to TestVNet4 connection.

PowerShell

Set-AzureVNetGatewayKey -VNetName 'Group ClassicRG TestVNet1' `
-LocalNetworkSiteName '17BE5E2C_VNet4Local' -SharedKey A1b2C3D4

Create the TestVNet4 to TestVNet1 connection.

PowerShell

Set-AzureVNetGatewayKey -VNetName 'Group ClassicRG TestVNet4' `
-LocalNetworkSiteName 'F7F7BFC7_VNet1Local' -SharedKey A1b2C3D4

Wait for the connections to initialize. Once the gateway has initialized, the Status is 'Successful'.

Error          :
HttpStatusCode : OK
Id             :
Status         : Successful
RequestId      :
StatusCode     : OK

VNet-to-VNet considerations for classic VNets

The virtual networks can be in the same or different subscriptions.
The virtual networks can be in the same or different Azure regions (locations).
A cloud service or a load balancing endpoint can't span across virtual networks, even if they are connected together.
Connecting multiple virtual networks together doesn't require any VPN devices.
VNet-to-VNet supports connecting Azure Virtual Networks. It does not support connecting virtual machines or cloud services that are not deployed to a virtual network.
VNet-to-VNet requires dynamic routing gateways. Azure static routing gateways are not supported.
Virtual network connectivity can be used simultaneously with multi-site VPNs. There is a maximum of 10 VPN tunnels for a virtual network VPN gateway connecting to either other virtual networks, or on-premises sites.
The address spaces of the virtual networks and on-premises local network sites must not overlap. Overlapping address spaces will cause the creation of virtual networks or uploading netcfg configuration files to fail.
Redundant tunnels between a pair of virtual networks are not supported.
All VPN tunnels for the VNet, including P2S VPNs, share the available bandwidth for the VPN gateway, and the same VPN gateway uptime SLA in Azure.
VNet-to-VNet traffic travels across the Azure backbone.

Hook yourself to CLOUD

Thursday 11 October 2018

Configure a VNet-to-VNet connection (classic)