Which connectivity method will you use to connect your on-premises VPN device to Azure VPN gateway?

Inhaltsverzeichnis Show

Article
4 minutes to read

It's important to know that there are different configurations available for VPN gateway connections. You need to determine which configuration best fits your needs. In the sections below, you can view design information and topology diagrams about the following VPN gateway connections. Use the diagrams and descriptions to help select the connection topology to match your requirements. The diagrams show the main baseline topologies, but it's possible to build more complex configurations using the diagrams as guidelines.

Site-to-Site VPN

A Site-to-Site (S2S) VPN gateway connection is a connection over IPsec/IKE (IKEv1 or IKEv2) VPN tunnel. S2S connections can be used for cross-premises and hybrid configurations. A S2S connection requires a VPN device located on-premises that has a public IP address assigned to it. For information about selecting a VPN device, see the VPN Gateway FAQ - VPN devices.

VPN Gateway can be configured in active-standby mode using one public IP or in active-active mode using two public IPs. In active-standby mode, one IPsec tunnel is active and the other tunnel is in standby. In this setup, traffic flows through the active tunnel, and if some issue happens with this tunnel, the traffic switches over to the standby tunnel. Setting up VPN Gateway in active-active mode is recommended in which both the IPsec tunnels are simultaneously active, with data flowing through both tunnels at the same time. An additional advantage of active-active mode is that customers experience higher throughputs.

You can create more than one VPN connection from your virtual network gateway, typically connecting to multiple on-premises sites. When working with multiple connections, you must use a RouteBased VPN type (known as a dynamic gateway when working with classic VNets). Because each virtual network can only have one VPN gateway, all connections through the gateway share the available bandwidth. This type of connection is sometimes referred to as a "multi-site" connection.

Deployment models and methods for S2S

(**) denotes that this method contains steps that require PowerShell.

Point-to-Site VPN

A Point-to-Site (P2S) VPN gateway connection lets you create a secure connection to your virtual network from an individual client computer. A P2S connection is established by starting it from the client computer. This solution is useful for telecommuters who want to connect to Azure VNets from a remote location, such as from home or a conference. P2S VPN is also a useful solution to use instead of S2S VPN when you have only a few clients that need to connect to a VNet.

Unlike S2S connections, P2S connections do not require an on-premises public-facing IP address or a VPN device. P2S connections can be used with S2S connections through the same VPN gateway, as long as all the configuration requirements for both connections are compatible. For more information about Point-to-Site connections, see About Point-to-Site VPN.

Deployment models and methods for P2S

Azure native certificate authentication

RADIUS authentication

Deployment model/method	Azure portal	PowerShell
Resource Manager	Supported	Tutorial
Classic	Not Supported	Not Supported

VNet-to-VNet connections (IPsec/IKE VPN tunnel)

Connecting a virtual network to another virtual network (VNet-to-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 even combine VNet-to-VNet communication with multi-site connection configurations. This lets you establish network topologies that combine cross-premises connectivity with inter-virtual network connectivity.

The VNets you connect can be:

in the same or different regions
in the same or different subscriptions
in the same or different deployment models

Connections between deployment models

Azure currently has two deployment models: classic and Resource Manager. If you have been using Azure for some time, you probably have Azure VMs and instance roles running in a classic VNet. Your newer VMs and role instances may be running in a VNet created in Resource Manager. You can create a connection between the VNets to allow the resources in one VNet to communicate directly with resources in another.

VNet peering

You may be able to use VNet peering to create your connection, as long as your virtual network meets certain requirements. VNet peering does not use a virtual network gateway. For more information, see VNet peering.

Deployment models and methods for VNet-to-VNet

(+) denotes this deployment method is available only for VNets in the same subscription.
(*) denotes that this deployment method also requires PowerShell.

Site-to-Site and ExpressRoute coexisting connections

ExpressRoute is a direct, private connection from your WAN (not over the public Internet) to Microsoft Services, including Azure. Site-to-Site VPN traffic travels encrypted over the public Internet. Being able to configure Site-to-Site VPN and ExpressRoute connections for the same virtual network has several advantages.

You can configure a Site-to-Site VPN as a secure failover path for ExpressRoute, or use Site-to-Site VPNs to connect to sites that are not part of your network, but that are connected through ExpressRoute. Notice that this configuration requires two virtual network gateways for the same virtual network, one using the gateway type 'Vpn', and the other using the gateway type 'ExpressRoute'.

Deployment models and methods for S2S and ExpressRoute coexist

Deployment model/method	Azure portal	PowerShell
Resource Manager	Supported	Tutorial
Classic	Not Supported	Tutorial

Highly available connections

For planning and design for highly available connections, see Highly available connections.

Next steps

Article
8 minutes to read

A VPN device is required to configure a Site-to-Site (S2S) cross-premises VPN connection using a VPN gateway. Site-to-Site connections can be used to create a hybrid solution, or whenever you want secure connections between your on-premises networks and your virtual networks. This article provides a list of validated VPN devices and a list of IPsec/IKE parameters for VPN gateways.

Items to note when viewing the tables:

There has been a terminology change for Azure VPN gateways. Only the names have changed. There is no functionality change.
- Static Routing = PolicyBased
- Dynamic Routing = RouteBased
Specifications for HighPerformance VPN gateway and RouteBased VPN gateway are the same, unless otherwise noted. For example, the validated VPN devices that are compatible with RouteBased VPN gateways are also compatible with the HighPerformance VPN gateway.

Validated VPN devices and device configuration guides

In partnership with device vendors, we have validated a set of standard VPN devices. All of the devices in the device families in the following list should work with VPN gateways. See About VPN Gateway Settings to understand the VPN type use (PolicyBased or RouteBased) for the VPN Gateway solution you want to configure.

To help configure your VPN device, refer to the links that correspond to the appropriate device family. The links to configuration instructions are provided on a best-effort basis. For VPN device support, contact your device manufacturer.

Note

(*) Cisco ASA versions 8.4+ add IKEv2 support, can connect to Azure VPN gateway using custom IPsec/IKE policy with "UsePolicyBasedTrafficSelectors" option. Refer to this how-to article.

(**) ISR 7200 Series routers only support PolicyBased VPNs.

Download VPN device configuration scripts from Azure

For certain devices, you can download configuration scripts directly from Azure. For more information and download instructions, see Download VPN device configuration scripts.

Non-validated VPN devices

If you don’t see your device listed in the Validated VPN devices table, your device still may work with a Site-to-Site connection. Contact your device manufacturer for additional support and configuration instructions.

Editing device configuration samples

After you download the provided VPN device configuration sample, you’ll need to replace some of the values to reflect the settings for your environment.

To edit a sample:

Open the sample using Notepad.
Search and replace all <text> strings with the values that pertain to your environment. Be sure to include < and >. When a name is specified, the name you select should be unique. If a command doesn't work, consult your device manufacturer documentation.

Sample text	Change to
<RP_OnPremisesNetwork>	Your chosen name for this object. Example: myOnPremisesNetwork
<RP_AzureNetwork>	Your chosen name for this object. Example: myAzureNetwork
<RP_AccessList>	Your chosen name for this object. Example: myAzureAccessList
<RP_IPSecTransformSet>	Your chosen name for this object. Example: myIPSecTransformSet
<RP_IPSecCryptoMap>	Your chosen name for this object. Example: myIPSecCryptoMap
<SP_AzureNetworkIpRange>	Specify range. Example: 192.168.0.0
<SP_AzureNetworkSubnetMask>	Specify subnet mask. Example: 255.255.0.0
<SP_OnPremisesNetworkIpRange>	Specify on-premises range. Example: 10.2.1.0
<SP_OnPremisesNetworkSubnetMask>	Specify on-premises subnet mask. Example: 255.255.255.0
<SP_AzureGatewayIpAddress>	This information specific to your virtual network and is located in the Management Portal as Gateway IP address.
<SP_PresharedKey>	This information is specific to your virtual network and is located in the Management Portal as Manage Key.

Default IPsec/IKE parameters

The tables below contain the combinations of algorithms and parameters Azure VPN gateways use in default configuration (Default policies). For route-based VPN gateways created using the Azure Resource Management deployment model, you can specify a custom policy on each individual connection. Refer to Configure IPsec/IKE policy for detailed instructions.

Additionally, you must clamp TCP MSS at 1350. Or if your VPN devices don't support MSS clamping, you can alternatively set the MTU on the tunnel interface to 1400 bytes instead.

In the following tables:

SA = Security Association
IKE Phase 1 is also called "Main Mode"
IKE Phase 2 is also called "Quick Mode"

IKE Phase 1 (Main Mode) parameters

Property	PolicyBased	RouteBased
IKE Version	IKEv1	IKEv1 and IKEv2
Diffie-Hellman Group	Group 2 (1024 bit)	Group 2 (1024 bit)
Authentication Method	Pre-Shared Key	Pre-Shared Key
Encryption & Hashing Algorithms	1. AES256, SHA2562. AES256, SHA13. AES128, SHA1 4. 3DES, SHA1	1. AES256, SHA12. AES256, SHA2563. AES128, SHA14. AES128, SHA2565. 3DES, SHA1 6. 3DES, SHA256
SA Lifetime	28,800 seconds	28,800 seconds

IKE Phase 2 (Quick Mode) parameters

Property	PolicyBased	RouteBased
IKE Version	IKEv1	IKEv1 and IKEv2
Encryption & Hashing Algorithms	1. AES256, SHA2562. AES256, SHA13. AES128, SHA1 4. 3DES, SHA1	RouteBased QM SA Offers
SA Lifetime (Time)	3,600 seconds	27,000 seconds
SA Lifetime (Bytes)	102,400,000 KB	102,400,000 KB
Perfect Forward Secrecy (PFS)	No	RouteBased QM SA Offers
Dead Peer Detection (DPD)	Not supported	Supported

RouteBased VPN IPsec Security Association (IKE Quick Mode SA) Offers

The following table lists IPsec SA (IKE Quick Mode) Offers. Offers are listed the order of preference that the offer is presented or accepted.

Azure Gateway as initiator

-	Encryption	Authentication	PFS Group
1	GCM AES256	GCM (AES256)	None
2	AES256	SHA1	None
3	3DES	SHA1	None
4	AES256	SHA256	None
5	AES128	SHA1	None
6	3DES	SHA256	None

-	Encryption	Authentication	PFS Group
1	GCM AES256	GCM (AES256)	None
2	AES256	SHA1	None
3	3DES	SHA1	None
4	AES256	SHA256	None
5	AES128	SHA1	None
6	3DES	SHA256	None
7	DES	SHA1	None
8	AES256	SHA1	1
9	AES256	SHA1	2
10	AES256	SHA1	14
11	AES128	SHA1	1
12	AES128	SHA1	2
13	AES128	SHA1	14
14	3DES	SHA1	1
15	3DES	SHA1	2
16	3DES	SHA256	2
17	AES256	SHA256	1
18	AES256	SHA256	2
19	AES256	SHA256	14
20	AES256	SHA1	24
21	AES256	SHA256	24
22	AES128	SHA256	None
23	AES128	SHA256	1
24	AES128	SHA256	2
25	AES128	SHA256	14
26	3DES	SHA1	14

You can specify IPsec ESP NULL encryption with RouteBased and HighPerformance VPN gateways. Null based encryption doesn't provide protection to data in transit, and should only be used when maximum throughput and minimum latency is required. Clients may choose to use this in VNet-to-VNet communication scenarios, or when encryption is being applied elsewhere in the solution.
For cross-premises connectivity through the Internet, use the default Azure VPN gateway settings with encryption and hashing algorithms listed in the tables above to ensure security of your critical communication.

Known device compatibility issues

Important

These are the known compatibility issues between third-party VPN devices and Azure VPN gateways. The Azure team is actively working with the vendors to address the issues listed here. Once the issues are resolved, this page will be updated with the most up-to-date information. Please check back periodically.

Feb. 16, 2017

Palo Alto Networks devices with version prior to 7.1.4 for Azure route-based VPN: If you're using VPN devices from Palo Alto Networks with PAN-OS version prior to 7.1.4 and are experiencing connectivity issues to Azure route-based VPN gateways, perform the following steps:

Check the firmware version of your Palo Alto Networks device. If your PAN-OS version is older than 7.1.4, upgrade to 7.1.4.
On the Palo Alto Networks device, change the Phase 2 SA (or Quick Mode SA) lifetime to 28,800 seconds (8 hours) when connecting to the Azure VPN gateway.
If you're still experiencing connectivity issues, open a support request from the Azure portal.