Create a Site-to-Site connection using the Azure portal (classic)

This article shows you how to use the Azure portal to create a Site-to-Site VPN gateway connection from your on-premises network to the VNet. The steps in this article apply to the classic (legacy) deployment model and don't apply to the current deployment model, Resource Manager. See the Resource Manager version of this article instead.

A Site-to-Site VPN gateway connection is used to connect your on-premises network to an Azure virtual network over an IPsec/IKE (IKEv1 or IKEv2) VPN tunnel. This type of connection requires a VPN device located on-premises that has an externally facing public IP address assigned to it. For more information about VPN gateways, see About VPN gateway.

Before you begin

Verify that you have met the following criteria before beginning configuration:

• Verify that you want to work in the classic deployment model. If you want to work in the Resource Manager deployment model, see Create a Site-to-Site connection (Resource Manager). We recommend that you use the Resource Manager deployment model, as the classic model is legacy.
• Make sure you have a compatible VPN device and someone who is able to configure it. For more information about compatible VPN devices and device configuration, see About VPN Devices.
• Verify that you have an externally facing public IPv4 address for your VPN device.
• If you're unfamiliar with the IP address ranges located in your on-premises network configuration, you need to coordinate with someone who can provide those details for you. When you create this configuration, you must specify the IP address range prefixes that Azure will route to your on-premises location. None of the subnets of your on-premises network can over lap with the virtual network subnets that you want to connect to.
• PowerShell is required in order to specify the shared key and create the VPN gateway connection. When working with the classic deployment model, you can't use Azure Cloud Shell. Instead, you must install the latest version of the Azure Service Management (SM) PowerShell cmdlets locally on your computer. These cmdlets are different from the AzureRM or Az cmdlets. To install the SM cmdlets, see Install Service Management cmdlets. For more information about Azure PowerShell in general, see the Azure PowerShell documentation.

Sample configuration values for this exercise

The examples in this article use the following values. You can use these values to create a test environment, or refer to them to better understand the examples in this article. Typically, when working with IP address values for Address space, you want to coordinate with your network administrator in order to avoid overlapping address spaces, which can affect routing. In this case, replace the IP address values with your own if you want to create a working connection.

• Resource Group: TestRG1
• VNet Name: TestVNet1
• Address space: 10.11.0.0/16
• Subnet name: FrontEnd
• Subnet address range: 10.11.0.0/24
• GatewaySubnet: 10.11.255.0/27
• Region: (US) East US
• Local site name: Site2
• Client address space: The address space that is located on your on-premises site.

Create a virtual network

When you create a virtual network to use for a S2S connection, you need to make sure that the address spaces that you specify don't overlap with any of the client address spaces for the local sites that you want to connect to. If you have overlapping subnets, your connection won't work properly.

• If you already have a VNet, verify that the settings are compatible with your VPN gateway design. Pay particular attention to any subnets that might overlap with other networks.

• If you don't already have a virtual network, create one. Screenshots are provided as examples. Be sure to replace the values with your own.

To create a virtual network

1. From a browser, navigate to the Azure portal and, if necessary, sign in with your Azure account.
2. Select +Create a resource. In the Search the marketplace field, type 'Virtual Network'. Locate Virtual Network from the returned list and select it to open the Virtual Network page.
3. On the Virtual Network page, under the Create button, you see "Deploy with Resource Manager (change to Classic)". Resource Manager is the default for creating a VNet. You don't want to create a Resource Manager VNet. Select (change to Classic) to create a Classic VNet. Then, select the Overview tab and select Create.
4. On the Create virtual network(classic) page, on the Basics tab, configure the VNet settings with the example values.
5. Select Review + create to validate your VNet.
6. Validation runs. After the VNet is validated, select Create.

DNS settings are not a required part of this configuration, but DNS is necessary if you want name resolution between your VMs. Specifying a value does not create a new DNS server. The DNS server IP address that you specify should be a DNS server that can resolve the names for the resources you are connecting to.

After you create your virtual network, you can add the IP address of a DNS server to handle name resolution. Open the settings for your virtual network, select DNS servers, and add the IP address of the DNS server that you want to use for name resolution.

1. Locate the virtual network in the portal.
2. On the page for your virtual network, under the Settings section, select DNS servers.
3. Add a DNS server.
4. To save your settings, select Save at the top of the page.

Configure the site and gateway

To configure the site

The local site typically refers to your on-premises location. It contains the IP address of the VPN device to which you'll create a connection, and the IP address ranges that will be routed through the VPN gateway to the VPN device.

1. On the page for your VNet, under Settings, select Site-to-site connections.

2. On the Site-to-site connections page, select + Add.

3. On the Configure a VPN connection and gateway page, for Connection type, leave Site-to-site selected. For this exercise, you'll need to use a combination of the example values and your own values.

   • VPN gateway IP address: This is the public IP address of the VPN device for your on-premises network. The VPN device requires an IPv4 public IP address. Specify a valid public IP address for the VPN device to which you want to connect. It must be reachable by Azure. If you don't know the IP address of your VPN device, you can always put in a placeholder value (as long as it is in the format of a valid public IP address) and then change it later.

   • Client Address space: List the IP address ranges that you want routed to the local on-premises network through this gateway. You can add multiple address space ranges. Make sure that the ranges you specify here don't overlap with ranges of other networks your virtual network connects to, or with the address ranges of the virtual network itself.

4. At the bottom of the page, DO NOT select Review + create. Instead, select Next: Gateway>.

To configure the virtual network gateway

1. On the Gateway page, select the following values:

   • Size: This is the gateway SKU that you use to create your virtual network gateway. Classic VPN gateways use the old (legacy) gateway SKUs. For more information about the legacy gateway SKUs, see Working with virtual network gateway SKUs (old SKUs). You can select Standard for this exercise.

   • Gateway subnet: The size of the gateway subnet that you specify depends on the VPN gateway configuration that you want to create. While it's possible to create a gateway subnet as small as /29, we recommend that you use /27 or /28. This creates a larger subnet that includes more addresses. Using a larger gateway subnet allows for enough IP addresses to accommodate possible future configurations.

2. Select Review + create at the bottom of the page to validate your settings. Select Create to deploy. It can take up to 45 minutes to create a virtual network gateway, depending on the gateway SKU that you selected.

Configure your VPN device

Site-to-Site connections to an on-premises network require a VPN device. In this step, you configure your VPN device. When configuring your VPN device, you need the following values:

• A shared key. This is the same shared key that you specify when creating your Site-to-Site VPN connection. In our examples, we use a basic shared key. We recommend that you generate a more complex key to use.
• The Public IP address of your virtual network gateway. You can view the public IP address by using the Azure portal, PowerShell, or CLI.

Depending on the VPN device that you have, you might be able to download a VPN device configuration script. For more information, see Download VPN device configuration scripts.

The following links provide more configuration information:

• For information about compatible VPN devices, see About VPN devices.

• Before you configure your VPN device, check for any known device compatibility issues.

• For links to device configuration settings, see Validated VPN devices. We provide the device configuration links on a best-effort basis, but it's always best to check with your device manufacturer for the latest configuration information.

  The list shows the versions that we tested. If the OS version for your VPN device isn't on the list, it still might be compatible. Check with your device manufacturer.

• For basic information about VPN device configuration, see Overview of partner VPN device configurations.

• For information about editing device configuration samples, see Editing samples.

• For cryptographic requirements, see About cryptographic requirements and Azure VPN gateways.

• For information about parameters that you need to complete your configuration, see Default IPsec/IKE parameters. The information includes IKE version, Diffie-Hellman (DH) group, authentication method, encryption and hashing algorithms, security association (SA) lifetime, perfect forward secrecy (PFS), and Dead Peer Detection (DPD).

• For IPsec/IKE policy configuration steps, see Configure custom IPsec/IKE connection policies for S2S VPN and VNet-to-VNet.

• To connect multiple policy-based VPN devices, see Connect a VPN gateway to multiple on-premises policy-based VPN devices.

Retrieve values

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. For a VNet in the resource group "ClassicRG" 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.

1. Download and install the latest version of the Azure Service Management (SM) PowerShell cmdlets. Most people have the Resource Manager modules installed locally, but do not have Service Management modules. Service Management modules are legacy and must be installed separately. For more information, see Install Service Management cmdlets.

2. Open your PowerShell console with elevated rights and connect to your account. Use the following examples to help you connect. You must run these commands locally using the PowerShell Service Management module. Connect to your account. Use the following example to help you connect:

   Add-AzureAccount
   

3. Check the subscriptions for the account.

   Get-AzureSubscription
   

4. If you have more than one subscription, select the subscription that you want to use.

   Select-AzureSubscription -SubscriptionId "Replace_with_your_subscription_ID"
   

5. Create a directory on your computer. For example, C:\AzureVNet

6. 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
   

7. Open the file with a text editor and view the names for your VNets and sites. These names will be the names you use when you create your connections.
   VNet names are listed as VirtualNetworkSite name =
   Site names are listed as LocalNetworkSiteRef name =

Create the connection

In this step, using the values from the previous steps, you set the shared key and create the connection. The key you set must be the same key that was used in your VPN device configuration.

1. Set the shared key and create the connection.

   • Change the -VNetName value and the -LocalNetworkSiteName value. When specifying a name that contains spaces, use single quotation marks around the value.
   • The '-SharedKey' is a value that you generate, and then specify. In the example, we used 'abc123', but you can (and should) generate something more complex. The important thing is that the value you specify here must be the same value that you specified when configuring your VPN device.

   Set-AzureVNetGatewayKey -VNetName 'Group TestRG1 TestVNet1' `
   -LocalNetworkSiteName '6C74F6E6_Site2' -SharedKey abc123
   

2. When the connection is created, the result is: Status: Successful.

Verify your connection

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.

1. In the Azure portal, go to your classic virtual network (VNet).
2. On the virtual network page, click the type of connection you want to view. For example, Site-to-site connections.
3. On the Site-to-site connections page, under Name, select the site connection you want to view.
4. On the Properties page, view the information about the connection.

If you're having trouble connecting, see the Troubleshoot section of the table of contents in the left pane.

How to reset a VPN gateway

Resetting an Azure VPN gateway is helpful if you lose cross-premises VPN connectivity on one or more Site-to-Site VPN tunnels. In this situation, your on-premises VPN devices are all working correctly, but aren't able to establish IPsec tunnels with the Azure VPN gateways.

The cmdlet for resetting a classic gateway is Reset-AzureVNetGateway. The Azure PowerShell cmdlets for Service Management must be installed locally on your desktop. You can't use Azure Cloud Shell. Before performing a reset, make sure you have the latest version of the Service Management (SM) PowerShell cmdlets.

When using this command, make sure you're using the full name of the virtual network. Classic VNets that were created using the portal have a long name that is required for PowerShell. You can view the long name by using Get-AzureVNetConfig -ExportToFile C:\Myfoldername\NetworkConfig.xml.

The following example resets the gateway for a virtual network named "Group TestRG1 TestVNet1" (which shows as simply "TestVNet1" in the portal):

Reset-AzureVNetGateway –VnetName 'Group TestRG1 TestVNet1'

Result:

Error          :
HttpStatusCode : OK
Id             : f1600632-c819-4b2f-ac0e-f4126bec1ff8
Status         : Successful
RequestId      : 9ca273de2c4d01e986480ce1ffa4d6d9
StatusCode     : OK

How to resize a gateway SKU

To resize a gateway for the classic deployment model, you must use the Service Management PowerShell cmdlets. Use the following command:

Resize-AzureVirtualNetworkGateway -GatewayId <Gateway ID> -GatewaySKU HighPerformance

Next steps

• Once your connection is complete, you can add virtual machines to your virtual networks. For more information, see Virtual Machines.
• For information about Forced Tunneling, see About Forced Tunneling.