Редагувати

Поділитися через

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 a custom IPsec/IKE policy supported on all Azure VPN Gateway SKUs?

A custom IPsec/IKE policy is supported on all Azure VPN Gateway SKUs except the Basic SKU.

How many policies can I specify on a connection?

You can specify only one policy combination for a 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 algorithms and key strengths does the custom policy support?

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
Quick Mode SA lifetime (Optional; default values if not specified)
Seconds (integer; minimum 300, default 27,000)
Kilobytes (integer; minimum 1,024, default 10,2400,000)
Traffic selector UsePolicyBasedTrafficSelectors ($True or $False, but optional; default $False if not specified)
DPD timeout Seconds (integer; minimum 9, maximum 3,600, default 45)

  • Your on-premises VPN device configuration must match or contain the following algorithms and parameters that you specify on the Azure IPsec or 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 you use UsePolicyBasedTrafficSelectors)
    • SA lifetimes (local specifications that don't need to match)

  • If you use GCMAES for the IPsec encryption algorithm, you must select the same GCMAES algorithm and key length for IPsec integrity. For example, use GCMAES128 for both.

  • In the table of algorithms and keys:

    • 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 specifies 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 configures the VPN gateway to connect to an on-premises policy-based VPN firewall.

    If you enable UsePolicyBasedTrafficSelectors, ensure that your VPN device has the matching traffic selectors defined with all combinations of your on-premises network (local network gateway) prefixes to or from the Azure virtual network prefixes, instead of any-to-any. The VPN gateway accepts whatever traffic selector the remote VPN gateway proposes, irrespective of what's configured on the 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 about policy-based traffic selectors, see Connect a VPN gateway to multiple on-premises policy-based VPN devices.

  • Setting the timeout to shorter periods causes IKE to rekey more aggressively. The connection can then appear to be disconnected in some instances. This situation might not be desirable if your on-premises locations are farther away from the Azure region where the VPN gateway resides, or if the physical link condition could incur packet loss. We generally recommend that you set the timeout to between 30 and 45 seconds.

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

Which Diffie-Hellman groups does the custom policy support?

The following table lists the corresponding Diffie-Hellman groups that the custom policy supports:

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

For more information, refer to RFC3526 and RFC5114.

Does the custom policy replace the default IPsec/IKE policy sets for VPN gateways?

Yes. After you specify a custom policy on a connection, Azure VPN Gateway uses only that 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, IPsec/IKE still helps protect the connection. After you remove the custom policy from a connection, the VPN gateway reverts to the default list of IPsec/IKE proposals and restarts the IKE handshake 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 VPN gateway tears down the existing connection and restarts the IKE handshake to reestablish the IPsec tunnel with the new cryptographic algorithms and parameters. Ensure that 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. A 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 a custom policy on VNet-to-VNet connections?

Yes. You can apply a custom policy on both IPsec cross-premises connections and 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 be established.

What is the default DPD timeout value? Can I specify a different DPD timeout?

The default DPD timeout is 45 seconds on VPN gateways. You can specify a different DPD timeout value on each IPsec or VNet-to-VNet connection, from 9 seconds to 3,600 seconds.

Note

Setting the timeout to shorter periods causes IKE to rekey more aggressively. The connection can then appear to be disconnected in some instances. This situation might not be desirable if your on-premises locations are farther away from the Azure region where the VPN gateway resides, or if the physical link condition could incur packet loss. We generally recommend that you set the timeout to between 30 and 45 seconds.

Does a custom IPsec/IKE policy work on ExpressRoute connections?

No. An IPsec/IKE policy works only on S2S VPN and VNet-to-VNet connections via the VPN gateways.

How do I create connections with the IKEv1 or IKEv2 protocol type?

You can create IKEv1 connections on all route-based VPN-type SKUs, except the Basic SKU, Standard SKU, and other earlier 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 Azure PowerShell cmdlet documentation.

For information about SKU types and support for IKEv1 and IKEv2, see Connect a VPN gateway to multiple on-premises policy-based VPN devices.

Is transit between IKEv1 and IKEv2 connections allowed?

Yes.

Can I have IKEv1 site-to-site connections on the Basic SKU for the route-based VPN type?

No. The Basic SKU doesn't support this configuration.

Can I change the connection protocol type after the connection is created (IKEv1 to IKEv2 and vice versa)?

No. After you create the connection, you can't change IKEv1 and IKEv2 protocols. You must delete and re-create 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 because your VPN gateways don't support in-place rekeys. When Main Mode is being rekeyed, your IKEv1 tunnels disconnect and take up to 5 seconds to reconnect. Your Main Mode negotiation timeout 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 the troubleshooting guide.

Where can I find more information and steps for configuration?

See the following articles:

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.