Azure VPN Gateway P2S User Groups separate address pool does not work with Machine Certificate (CertificateGroupId)

Welcome to Microsoft Q&A.

I hope you are doing well @Maciej Kurzeja

Yes, CertificateGroupId is supported for certificate-based P2S authentication, and Microsoft documents that the certificate-based multiple address pool selection is performed using the Subject/Common Name (CN) of the client certificate.

The important detail in your configuration is this:

Certificate CN = <devicename>.contoso.com

while your:

CertificateGroupId = contoso.com

Microsoft's documentation states that the CertificateGroupId value is based on the certificate's Common Name (CN). It also specifically notes that the multiple address pool selection does not use the SAN for matching. If a SAN is present, Microsoft recommends that it match the Subject value.

Therefore, I would first test the configuration with the CertificateGroupId matching the actual certificate Subject/CN value.

For example, if the machine certificate is:

Subject: CN=PC001.contoso.com

configure the policy member with:

CertificateGroupId = PC001.contoso.com

If your intention is to place multiple machines into the same address pool, you would need a certificate naming scheme that allows the same CN/group value to be used for those certificates, rather than relying on the DNS suffix alone.

You can verify the certificate on the Windows device with:

Get-ChildItem Cert:\LocalMachine\My |

    Select-Object Subject, DnsNameList, EnhancedKeyUsageList

Also check the certificate directly in certlm.msc and look under Details → Subject to confirm the exact CN value.

Regarding machine certificates / Device Tunnel

The Microsoft documentation describes the matching mechanism as certificate Subject/CN and does not state that CertificateGroupId is limited to user certificates. Therefore, I would not treat the fact that this is an Always On VPN Device Tunnel as the primary issue.

The first thing I would validate is whether the CertificateGroupId exactly matches the Subject/CN being presented by the machine certificate.

Microsoft also explicitly states that the multiple address pool selection does not work with SAN-based matching. https://learn.microsoft.com/en-us/azure/vpn-gateway/point-to-site-user-groups-create-portal

Microsoft documentation

• Assign Users IP Addresses from Defined Pools for P2S VPN Connections https://learn.microsoft.com/en-us/azure/vpn-gateway/point-to-site-user-groups-create-portal
• Assign Users IP Addresses from Defined Pools for P2S VPN Connections – PowerShell https://learn.microsoft.com/en-us/azure/vpn-gateway/point-to-site-user-groups-create
• About Azure Point-to-Site VPN connections https://learn.microsoft.com/en-us/azure/vpn-gateway/point-to-site-about

Based on the configuration you provided, I would start by changing/testing the CertificateGroupId against the exact CN of the machine certificate rather than contoso.com. If that works, it confirms that the issue is the group matching value rather than the Device Tunnel itself.

If this answer helped clarify the platform capabilities and save you troubleshooting time, please consider marking it as Accepted. This helps others in the community find similar solutions.

@Jose Benjamin Solis Nolasco

I also tried using the full certificate Subject as the CertificateGroupId:

Subject: CN=PC001.contoso.com

and configured the policy member as:

CertificateGroupId = PC001.contoso.com

Unfortunately, this is still not working. The PC001 Device Tunnel is established successfully, but the client receives an IP address from the default address pool instead of the dedicated pool assigned to the CertificateGroupId policy group.

This leads me to my main question:

Does CertificateGroupId / P2S User Groups / Multiple Address Pools support a machine certificate used by Windows Always On VPN Device Tunnel?

I cannot find clear documentation from Microsoft confirming that this scenario is supported.

I have reviewed the Microsoft documentation and several diagrams/examples. However, the certificate examples appear to use user certificates rather than machine certificates.

For example, this Microsoft sample for Virtual WAN shows:

https://learn.microsoft.com/en-us/samples/azure/azure-quickstart-templates/virtual-wan-multiple-address-pool/

The certificate example is:

CN=******@sales.contoso.com

which appears to represent a user identity rather than a machine identity.

The same applies to the documentation you shared:

https://learn.microsoft.com/en-us/azure/vpn-gateway/point-to-site-user-groups-create-portal

The example uses:

******@finance.contoso.com

Again, this looks like a user certificate rather than a machine/device certificate.

In my case, the certificate is a machine certificate used by the Windows Always On VPN Device Tunnel, for example:

CN=PC001.contoso.com

The IKEv2 Device Tunnel itself works correctly and certificate authentication succeeds. The only issue is that the client is always assigned an address from the default P2S pool instead of the pool associated with the CertificateGroupId policy group.

Could you please confirm whether machine certificates used for Windows Device Tunnel are supported with CertificateGroupId and separate P2S address pools?

The fact that the Device Tunnel is successfully established proves that the machine certificate authentication itself is working. The VPN Gateway accepts the client certificate because it is issued by the trusted Root CA and meets the certificate requirements. However, the User Groups / Multiple Address Pools mechanism appears to be a separate layer, and this is where the machine certificate is not being matched to the CertificateGroupId policy group.