Azure VPN Gateway IKEv2 Certificate Authentication – User Group Selection Can Be Manipulated Through macOS Local ID

Environment:

• Azure VPN Gateway

Point-to-Site VPN

IKEv2

Certificate Authentication

macOS native IKEv2 VPN client

Issue Description:

We discovered unexpected behavior when using certificate-based IKEv2 authentication with Azure VPN Gateway User Groups.

The Azure VPN Gateway appears to select the User Group and corresponding IP address pool based on the Local ID (IKE IDi) provided by the macOS client, rather than strictly validating it against the client certificate's Common Name (CN).

Steps to Reproduce:

Configure two Azure VPN User Groups with different certificate identifiers and IP address pools.

Use the same client certificate and private key for all connection attempts.

Connect from macOS using IKEv2.

Change only the Local ID in the macOS VPN configuration:

******@abc.com

  `******@defg.com`
  
     `user1`
     
     Observe the IP address assigned by Azure VPN Gateway.
     

Actual Result:

The same client certificate can successfully connect using different Local IDs, and Azure assigns IP addresses from different User Group address pools based on the supplied Local ID.

Expected Result:

Azure should validate the IKEv2 identity against the authenticated client certificate and prevent a client from selecting a different User Group simply by changing the Local ID.

Questions:

Is this the expected behavior of Azure VPN Gateway's IKEv2 certificate authentication?

Which exact identity field is used to select the Azure VPN User Group: IKE IDi, certificate CN, or another field?

Is there a supported configuration to enforce strict binding between the IKEv2 Local ID and the authenticated client certificate?

Does this behavior represent a security vulnerability or a known limitation?

We would appreciate confirmation from the Azure VPN Gateway engineering team.Environment:

Azure VPN Gateway

Point-to-Site VPN

IKEv2

Certificate Authentication

macOS native IKEv2 VPN client

Issue Description:

We discovered unexpected behavior when using certificate-based IKEv2 authentication with Azure VPN Gateway User Groups.

The Azure VPN Gateway appears to select the User Group and corresponding IP address pool based on the Local ID (IKE IDi) provided by the macOS client, rather than strictly validating it against the client certificate's Common Name (CN).

Steps to Reproduce:

Configure two Azure VPN User Groups with different certificate identifiers and IP address pools.

Use the same client certificate and private key for all connection attempts.

Connect from macOS using IKEv2.

1. Change only the Local ID in the macOS VPN configuration:
   • ******@test01.com
   user1 Observe the IP address assigned by Azure VPN Gateway.

Actual Result:

The same client certificate can successfully connect using different Local IDs, and Azure assigns IP addresses from different User Group address pools based on the supplied Local ID.

Expected Result:

Azure should validate the IKEv2 identity against the authenticated client certificate and prevent a client from selecting a different User Group simply by changing the Local ID.

Questions:

Is this the expected behavior of Azure VPN Gateway's IKEv2 certificate authentication?

Which exact identity field is used to select the Azure VPN User Group: IKE IDi, certificate CN, or another field?

Is there a supported configuration to enforce strict binding between the IKEv2 Local ID and the authenticated client certificate?

Does this behavior represent a security vulnerability or a known limitation?

We would appreciate confirmation from the Azure VPN Gateway engineering team.