About cryptographic requirements and Azure VPN gateways
This article discusses how you can configure Azure VPN gateways to satisfy your cryptographic requirements for both cross-premises S2S VPN tunnels and VNet-to-VNet connections within Azure.
About IKEv1 and IKEv2 for Azure VPN connections
Traditionally we allowed IKEv1 connections for Basic SKUs only and allowed IKEv2 connections for all VPN gateway SKUs other than Basic SKUs. The Basic SKUs allow only 1 connection and along with other limitations such as performance, customers using legacy devices that support only IKEv1 protocols were having limited experience. In order to enhance the experience of customers using IKEv1 protocols, we are now allowing IKEv1 connections for all of the VPN gateway SKUs, except Basic SKU. For more information, see VPN Gateway SKUs. Note that VPN gateways using IKEv1 might experience up tunnel reconnects during Main mode rekeys.
When IKEv1 and IKEv2 connections are applied to the same VPN gateway, the transit between these two connections is auto-enabled.
About IPsec and IKE policy parameters for Azure VPN gateways
IPsec and IKE protocol standard supports a wide range of cryptographic algorithms in various combinations. If you do not request a specific combination of cryptographic algorithms and parameters, Azure VPN gateways use a set of default proposals. The default policy sets were chosen to maximize interoperability with a wide range of third-party VPN devices in default configurations. As a result, the policies and the number of proposals cannot cover all possible combinations of available cryptographic algorithms and key strengths.
The default policy set for Azure VPN gateway is listed in the article: About VPN devices and IPsec/IKE parameters for Site-to-Site VPN Gateway connections.
For communications that require specific cryptographic algorithms or parameters, typically due to compliance or security requirements, you can now configure their Azure VPN gateways to use a custom IPsec/IKE policy with specific cryptographic algorithms and key strengths, rather than the Azure default policy sets.
For example, the IKEv2 main mode policies for Azure VPN gateways utilize only Diffie-Hellman Group 2 (1024 bits), whereas you may need to specify stronger groups to be used in IKE, such as Group 14 (2048-bit), Group 24 (2048-bit MODP Group), or ECP (elliptic curve groups) 256 or 384 bit (Group 19 and Group 20, respectively). Similar requirements apply to IPsec quick mode policies as well.
Custom IPsec/IKE policy with Azure VPN gateways
Azure VPN gateways now support per-connection, custom IPsec/IKE policy. For a Site-to-Site or VNet-to-VNet connection, you can choose a specific combination of cryptographic algorithms for IPsec and IKE with the desired key strength, as shown in the following example:
You can create an IPsec/IKE policy and apply to a new or existing connection.
- Create the virtual networks, VPN gateways, or local network gateways for your connectivity topology as described in other how-to documents
- Create an IPsec/IKE policy
- You can apply the policy when you create a S2S or VNet-to-VNet connection
- If the connection is already created, you can apply or update the policy to an existing connection
IPsec/IKE policy FAQ
Is Custom IPsec/IKE policy supported on all Azure VPN Gateway SKUs?
Custom IPsec/IKE policy is supported on all Azure SKUs except the Basic SKU.
How many policies can I specify on a connection?
You can only specify one policy combination for a given connection.
Can I specify a partial policy on a connection? (for example, only IKE algorithms, but not IPsec)
No, you must specify all algorithms and parameters for both IKE (Main Mode) and IPsec (Quick Mode). Partial policy specification isn't allowed.
What are the algorithms and key strengths supported in the custom policy?
The following table lists the supported cryptographic algorithms and key strengths configurable by the customers. You must select one option for every field.
|IKEv2 Encryption||GCMAES256, GCMAES128, AES256, AES192, AES128, DES3, DES|
|IKEv2 Integrity||GCMAES256, GCMAES128, SHA384, SHA256, SHA1, MD5|
|DH Group||DHGroup24, ECP384, ECP256, DHGroup14 (DHGroup2048), DHGroup2, DHGroup1, None|
|IPsec Encryption||GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, None|
|IPsec Integrity||GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5|
|PFS Group||PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, None|
|QM SA Lifetime||Seconds (integer; min. 300/default 27000 seconds)
KBytes (integer; min. 1024/default 102400000 KBytes)
|Traffic Selector||UsePolicyBasedTrafficSelectors ($True/$False; default $False)|
- DHGroup2048 & PFS2048 are the same as Diffie-Hellman Group 14 in IKE and IPsec PFS. See Diffie-Hellman Groups for the complete mappings.
- For GCMAES algorithms, you must specify the same GCMAES algorithm and key length for both IPsec Encryption and Integrity.
- IKEv2 Main Mode SA lifetime is fixed at 28,800 seconds on the Azure VPN gateways.
- QM SA Lifetimes are optional parameters. If none was specified, default values of 27,000 seconds (7.5 hrs) and 102400000 KBytes (102GB) are used.
- UsePolicyBasedTrafficSelector is an option parameter on the connection. See the next FAQ item for "UsePolicyBasedTrafficSelectors".
Does everything need to match between the Azure VPN gateway policy and my on-premises VPN device configurations?
Your on-premises VPN device configuration must match or contain the following algorithms and parameters that you specify on the Azure IPsec/IKE policy:
- IKE encryption algorithm
- IKE integrity algorithm
- DH Group
- IPsec encryption algorithm
- IPsec integrity algorithm
- PFS Group
- Traffic Selector (*)
The SA lifetimes are local specifications only, don't need to match.
If you enable UsePolicyBasedTrafficSelectors, you need to ensure your VPN device has the matching traffic selectors defined with all combinations of your on-premises network (local network gateway) prefixes to/from the Azure virtual network prefixes, instead of any-to-any. For example, if your on-premises network prefixes are 10.1.0.0/16 and 10.2.0.0/16, and your virtual network prefixes are 192.168.0.0/16 and 172.16.0.0/16, you need to specify the following traffic selectors:
- 10.1.0.0/16 <====> 192.168.0.0/16
- 10.1.0.0/16 <====> 172.16.0.0/16
- 10.2.0.0/16 <====> 192.168.0.0/16
- 10.2.0.0/16 <====> 172.16.0.0/16
For more information, see Connect multiple on-premises policy-based VPN devices.
The table below lists the supported Diffie-Hellman Groups for IKE (DHGroup) and IPsec (PFSGroup):
|Diffie-Hellman Group||DHGroup||PFSGroup||Key length|
Does the custom policy replace the default IPsec/IKE policy sets for Azure VPN gateways?
Yes, once a custom policy is specified on a connection, Azure VPN gateway will only use the policy on the connection, both as IKE initiator and IKE responder.
If I remove a custom IPsec/IKE policy, does the connection become unprotected?
No, the connection will still be protected by IPsec/IKE. Once you remove the custom policy from a connection, the Azure VPN gateway reverts back to the default list of IPsec/IKE proposals and restart the IKE handshake again with your on-premises VPN device.
Would adding or updating an IPsec/IKE policy disrupt my VPN connection?
Yes, it could cause a small disruption (a few seconds) as the Azure VPN gateway tears down the existing connection and restarts the IKE handshake to re-establish the IPsec tunnel with the new cryptographic algorithms and parameters. Ensure your on-premises VPN device is also configured with the matching algorithms and key strengths to minimize the disruption.
Can I use different policies on different connections?
Yes. Custom policy is applied on a per-connection basis. You can create and apply different IPsec/IKE policies on different connections. You can also choose to apply custom policies on a subset of connections. The remaining ones use the Azure default IPsec/IKE policy sets.
Can I use the custom policy on VNet-to-VNet connection as well?
Yes, you can apply custom policy on both IPsec cross-premises connections or VNet-to-VNet connections.
Do I need to specify the same policy on both VNet-to-VNet connection resources?
Yes. A VNet-to-VNet tunnel consists of two connection resources in Azure, one for each direction. Make sure both connection resources have the same policy, otherwise the VNet-to-VNet connection won't establish.
What is the default DPD timeout value? Can I specify a different DPD timeout?
The default DPD timeout is 45 seconds. You can specify a different DPD timeout value on each IPsec or VNet-to-VNet connection between 9 seconds to 3600 seconds.
Does custom IPsec/IKE policy work on ExpressRoute connection?
No. IPsec/IKE policy only works on S2S VPN and VNet-to-VNet connections via the Azure VPN gateways.
How do I create connections with IKEv1 or IKEv2 protocol type?
IKEv1 connections can be created on all RouteBased VPN type SKUs, except the Basic SKU, Standard SKU, and other legacy SKUs. You can specify a connection protocol type of IKEv1 or IKEv2 while creating connections. If you don't specify a connection protocol type, IKEv2 is used as default option where applicable. For more information, see the PowerShell cmdlet documentation. For SKU types and IKEv1/IKEv2 support, see Connect gateways to policy-based VPN devices.
Is transit between IKEv1 and IKEv2 connections allowed?
Yes. Transit between IKEv1 and IKEv2 connections is supported.
Can I have IKEv1 site-to-site connections on Basic SKUs of RouteBased VPN type?
No. The Basic SKU doesn't support this.
Can I change the connection protocol type after the connection is created (IKEv1 to IKEv2 and vice versa)?
No. Once the connection is created, IKEv1/IKEv2 protocols can't be changed. You must delete and recreate a new connection with the desired protocol type.
Why is my IKEv1 connection frequently reconnecting?
If your static routing or route based IKEv1 connection is disconnecting at routine intervals, it's likely due to VPN gateways not supporting in-place rekeys. When Main mode is getting rekeyed, your IKEv1 tunnels will disconnect and take up to 5 seconds to reconnect. Your Main mode negotiation time out value will determine the frequency of rekeys. To prevent these reconnects, you can switch to using IKEv2, which supports in-place rekeys.
If your connection is reconnecting at random times, follow our troubleshooting guide.
Where can I find more configuration information for IPsec?
See Configure IPsec/IKE policy for step-by-step instructions on configuring custom IPsec/IKE policy on a connection.
See also Connect multiple policy-based VPN devices to learn more about the UsePolicyBasedTrafficSelectors option.
Submit and view feedback for