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're 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.

Diagram showing IKEv1 and IKEv2 connections to the same gateway.

When IKEv1 and IKEv2 connections are applied to the same VPN gateway, the transit between these two connections is autoenabled.

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 don't 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 can't cover all possible combinations of available cryptographic algorithms and key strengths.

Default policy

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.

Cryptographic requirements

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:

Diagram showing custom policies per connection.

You can create an IPsec/IKE policy and apply to a new or existing connection.

Workflow

  1. Create the virtual networks, VPN gateways, or local network gateways for your connectivity topology as described in other how-to documents.
  2. Create an IPsec/IKE policy.
  3. You can apply the policy when you create a S2S or VNet-to-VNet connection.
  4. 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 that you can configure. You must select one option for every field.

IPsec/IKEv2 Options
IKEv2 Encryption GCMAES256, GCMAES128, AES256, AES192, AES128
IKEv2 Integrity 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 (Optional: default values are used if not specified)
Seconds (integer; min. 300/default 27000 seconds)
KBytes (integer; min. 1024/default 102400000 KBytes)
Traffic Selector UsePolicyBasedTrafficSelectors** ($True/$False; Optional, default $False if not specified)
DPD timeout Seconds (integer: min. 9/max. 3600; default 45 seconds)
  • 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 (Main Mode / Phase 1)
    • IKE integrity algorithm (Main Mode / Phase 1)
    • DH Group (Main Mode / Phase 1)
    • IPsec encryption algorithm (Quick Mode / Phase 2)
    • IPsec integrity algorithm (Quick Mode / Phase 2)
    • PFS Group (Quick Mode / Phase 2)
    • Traffic Selector (if UsePolicyBasedTrafficSelectors is used)
    • The SA lifetimes are local specifications only, and don't need to match.
  • If GCMAES is used as for IPsec Encryption algorithm, you must select the same GCMAES algorithm and key length for IPsec Integrity; for example, using GCMAES128 for both.

  • In the Algorithms and keys table:

    • IKE corresponds to Main Mode or Phase 1.
    • IPsec corresponds to Quick Mode or Phase 2.
    • DH Group specifies the Diffie-Hellman Group used in Main Mode or Phase 1.
    • PFS Group specified the Diffie-Hellman Group used in Quick Mode or Phase 2.
  • IKE Main Mode SA lifetime is fixed at 28,800 seconds on the Azure VPN gateways.

  • 'UsePolicyBasedTrafficSelectors' is an optional parameter on the connection. If you set UsePolicyBasedTrafficSelectors to $True on a connection, it will configure the Azure VPN gateway to connect to policy-based VPN firewall on premises. If you enable PolicyBasedTrafficSelectors, 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. The Azure VPN gateway accepts whatever traffic selector is proposed by the remote VPN gateway irrespective of what is configured on the Azure VPN gateway.

    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 regarding policy-based traffic selectors, see Connect multiple on-premises policy-based VPN devices.

  • DPD timeout - The default value is 45 seconds on Azure VPN gateways. Setting the timeout to shorter periods will cause IKE to rekey more aggressively, causing the connection to appear to be disconnected in some instances. This may not be desirable if your on-premises locations are farther away from the Azure region where the VPN gateway resides, or the physical link condition could incur packet loss. The general recommendation is to set the timeout between 30 to 45 seconds.

For more information, see Connect multiple on-premises policy-based VPN devices.

Which Diffie-Hellman Groups are supported?

The following table lists the corresponding Diffie-Hellman groups supported by the custom policy:

Diffie-Hellman Group DHGroup PFSGroup Key length
1 DHGroup1 PFS1 768-bit MODP
2 DHGroup2 PFS2 1024-bit MODP
14 DHGroup14
DHGroup2048
PFS2048 2048-bit MODP
19 ECP256 ECP256 256-bit ECP
20 ECP384 ECP384 384-bit ECP
24 DHGroup24 PFS24 2048-bit MODP

Refer to RFC3526 and RFC5114 for more details.

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, from 9 seconds to 3600 seconds.

Note

The default value is 45 seconds on Azure VPN gateways. Setting the timeout to shorter periods will cause IKE to rekey more aggressively, causing the connection to appear to be disconnected in some instances. This may not be desirable if your on-premises locations are farther away from the Azure region where the VPN gateway resides, or when the physical link condition could incur packet loss. The general recommendation is to set the timeout between 30 and 45 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 determines 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 configuration information and steps?

See the following articles for more information and configuration steps.

Next steps

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.