An Azure service that enables the connection of on-premises networks to Azure through site-to-site virtual private networks.
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:
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.