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 deployment model and do not apply to the current deployment model, Resource Manager. You can also create this configuration using a different deployment tool or deployment model by selecting a different option from the following list:

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.

Site-to-Site VPN Gateway cross-premises connection diagram

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 are 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 do not 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 may 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 will 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 will 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 do not 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.

    • Routing type: Select the routing type for your gateway. This is also known as the VPN type. It's important to select the correct type because you cannot convert the gateway from one type to another. Your VPN device must be compatible with the routing type you select. For more information about Routing Type, see About VPN Gateway Settings. You may see articles referring to 'RouteBased' and 'PolicyBased' VPN types. 'Dynamic' corresponds to 'RouteBased', and 'Static' corresponds to' PolicyBased'. Typically, you want Dynamic routing.

    • Gateway subnet: The size of the gateway subnet that you specify depends on the VPN gateway configuration that you want to create. While it is 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.

To download VPN device configuration scripts:

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

See the following links for additional configuration information:

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

Note

For the classic deployment model, this step is not available in the Azure portal or via Azure Cloud Shell. You must use the Service Management (SM) version of the Azure PowerShell cmdlets locally from your desktop.

In this step, using the values from the previous steps, you set the shared key and create the connection. The key you set is 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, click All resources and navigate to your classic virtual network.

  2. On the virtual network blade, click Overview to access the VPN connections section of the blade.

  3. On the VPN connections graphic, click the site.

    Local site

  4. On the Site-to-site VPN connections blade, view the information about your site.

    Connection status

  5. To view more information about the connection, click the name of the connection to open the Site-to-site VPN Connection blade.

    Connection status more

If you are 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 are not able to establish IPsec tunnels with the Azure VPN gateways. For steps, see Reset a VPN gateway.

How to change a gateway SKU

For steps to change a gateway SKU, see Resize a gateway SKU.

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.