Skip to main content

Technical Lab: Create and configure an IPsec/Internet Key Exchange (IKE) policy

Questions​

Question 1 — Multiple Choice​

A network architect needs to establish a Site-to-Site VPN tunnel between Azure and a legacy on-premises device that only supports IKEv1. When configuring the IPsec/IKE policy in Azure, which statement correctly describes the expected behavior?

A) Azure automatically negotiates between IKEv1 and IKEv2 based on the remote device's offer, without requiring explicit configuration.

B) A custom IPsec/IKE policy applied to a VPN connection allows specifying IKEv1, but only on gateways with SKU VpnGw1 or higher.

C) Azure supports IKEv1 in Site-to-Site connections with route-based gateways, but not with policy-based gateways.

D) To use IKEv1, you must leave the IPsec/IKE policy as default, since custom policies in Azure mandatory require IKEv2.

Question 2 — Technical Scenario​

A team configures a Site-to-Site VPN connection with a custom IPsec/IKE policy. After applying the configuration below via PowerShell, the tunnel does not establish connectivity with the on-premises device:

$ipsecPolicy = New-AzIpsecPolicy `
  -IkeEncryption AES256 `
  -IkeIntegrity SHA256 `
  -DhGroup DHGroup14 `
  -IpsecEncryption AES256 `
  -IpsecIntegrity SHA256 `
  -PfsGroup PFS2048 `
  -SALifeTimeSeconds 3600 `
  -SADataSizeKilobytes 0

The on-premises device is configured with SA lifetime of 3600 seconds and PFS Group 2. What most likely prevents tunnel establishment?

A) The value SADataSizeKilobytes 0 disables the volume limit, which is not supported by Azure in custom policies.

B) The PfsGroup PFS2048 in Azure does not match the PFS Group 2 configured on the remote device, causing phase 2 negotiation failure.

C) The parameter DhGroup DHGroup14 is incompatible with IkeEncryption AES256 in custom IKEv2 policies.

D) The combination of IkeIntegrity SHA256 with IpsecIntegrity SHA256 is not allowed in a single IPsec/IKE policy in Azure.

Question 3 — True or False​

A custom IPsec/IKE policy applied to a VPN Gateway connection in Azure completely replaces the default policy and prevents the gateway from using any other algorithm combinations during negotiation, even if the remote device offers additional proposals.

( ) True ( ) False

Question 4 — Technical Scenario​

An organization needs its Site-to-Site VPN connection to meet compliance requirements that mandate Perfect Forward Secrecy (PFS) and the use of elliptic curves for key exchange in phase 2. When reviewing the current configuration, the engineer identifies the following excerpt:

$ipsecPolicy = New-AzIpsecPolicy `
  -IkeEncryption GCMAES256 `
  -IkeIntegrity GCMAES256 `
  -DhGroup ECP384 `
  -IpsecEncryption GCMAES256 `
  -IpsecIntegrity GCMAES256 `
  -PfsGroup None `
  -SALifeTimeSeconds 27000

What is the problem with this configuration regarding the compliance requirement?

A) Using GCMAES256 for both encryption and integrity is redundant and invalid in Azure IPsec/IKE policies.

B) The PfsGroup None disables PFS in phase 2, directly violating the mandatory Perfect Forward Secrecy requirement.

C) The DhGroup ECP384 is not compatible with IpsecEncryption GCMAES256, making the policy invalid in Azure.

D) The value SALifeTimeSeconds 27000 is outside the allowed range for policies using GCMAES algorithms.

Question 5 — Multiple Choice​

When comparing the behavior of default IPsec/IKE policies with custom IPsec/IKE policies in Azure VPN Gateway, which of the statements below is technically correct?

A) The default Azure VPN Gateway policy uses a fixed and unique set of algorithms for all connections, without supporting dynamic negotiation with the remote device.

B) A custom policy can be applied simultaneously to multiple connections of the same gateway, as long as all connections are Site-to-Site type.

C) The custom policy applies only to the specific connection to which it is associated; other connections of the same gateway continue using the default policy or their own policies.

D) Custom policies can only be created and associated with connections during the gateway's initial creation; it's not possible to modify them after the gateway is active.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: A

Azure VPN Gateway supports both IKEv1 and IKEv2 in Site-to-Site connections with route-based gateways. When no custom policy is applied, the gateway uses the default policy and automatically negotiates the IKE version based on the proposal sent by the remote device. This means IKEv1 is accepted without explicit configuration, as long as the gateway is route-based.

The main misconception represented by the distractors is associating IKEv1 support with SKU restrictions or the mandatory use of custom policies. In reality, custom policies in Azure require specifying the IKE version, but the absence of a custom policy does not block IKEv1. Policy-based gateways, on the other hand, have their own restrictions that do not apply here.

Answer Key — Question 2​

Answer: B

The critical point is the correct mapping between PFS groups. In Azure, PFS2048 corresponds to Group 14 of the MODP standard, while PFS Group 2 of the on-premises device corresponds to MODP group 1024, represented in Azure as PFS2. Since the groups are different, phase 2 negotiation (Quick Mode in IKEv1 / Child SA in IKEv2) fails due to lack of compatible proposal.

The value SADataSizeKilobytes 0 is valid in Azure and indicates that the volume limit is disabled. The combination of DhGroup DHGroup14 with AES256 is supported, and using the same integrity algorithm in both phases is allowed. The error is exclusively in the incompatible PFS group between both sides of the tunnel.

Answer Key — Question 3​

Answer: True

When a custom IPsec/IKE policy is applied to a connection, Azure sends to the remote device exactly and only the algorithms and parameters defined in that policy. There is no additional negotiation with other combinations. The remote device must accept exactly that proposal; otherwise, the tunnel is not established.

This behavior is different from the default policy, which sends multiple proposals during negotiation. The custom policy is, by design, restrictive: it ensures compliance with an exact set of algorithms, but requires both sides to be precisely aligned. Understanding this distinction is fundamental for diagnosing tunnel failures after customizations.

Answer Key — Question 4​

Answer: B

The PfsGroup None explicitly disables Perfect Forward Secrecy in phase 2 of IPsec negotiation. Even though phase 1 (IKE) uses ECP384 for key exchange and robust algorithms like GCMAES256, the absence of PFS in phase 2 means session keys derive from the same keying material as phase 1. If this key is compromised in the future, all past sessions can be decrypted, directly violating the compliance requirement.

Using GCMAES256 for both encryption and integrity is valid in Azure, as AEAD algorithms like GCM incorporate authentication internally. The DhGroup ECP384 is compatible with GCMAES256, and SALifeTimeSeconds 27000 is within the range supported by Azure.

Answer Key — Question 5​

Answer: C

In Azure VPN Gateway, a custom IPsec/IKE policy has individual connection scope. This means it is associated with a specific connection and does not affect other connections of the same gateway. Each connection can have its own custom policy or use the gateway's default policy independently.

The default policy, contrary to what alternative A suggests, sends multiple algorithm proposals during negotiation, not a single fixed set. Alternative B is incorrect because there is no limitation preventing applying policies to multiple connections, but each association is individual per connection, not a batch configuration. Alternative D is incorrect because custom policies can be created, modified, and associated with existing connections at any time via portal, PowerShell, or CLI.