About user groups and IP address pools for P2S User VPNs
You can configure P2S User VPNs to assign users IP addresses from specific address pools based on their identity or authentication credentials by creating User Groups. This article describes the different configurations and parameters the Virtual WAN P2S VPN gateway uses to determine user groups and assign IP addresses. For configuration steps, see Configure user groups and IP address pools for P2S User VPNs.
This article covers the following concepts:
- Server configuration concepts
- User groups
- Group members
- Default policy group
- Group priority
- Available group settings
- Gateway concepts
- Configuration requirements and limitations
- Use cases
Server configuration concepts
The following sections explain the common terms and values used for server configuration.
User Groups (policy groups)
A User Group or policy group is a logical representation of a group of users that should be assigned IP addresses from the same address pool.
Group members (policy members)
User groups consist of members. Members don't correspond to individual users but rather define the criteria used to determine which group a connecting user is a part of. A single group can have multiple members. If a connecting user matches the criteria specified for one of the group's members, the user is considered to be part of that group and can be assigned an appropriate IP address. The types of member parameters that are available depend on the authentication methods specified in the VPN server configuration. For a full list of available criteria, see the Available group settings section of this article.
Default user/policy group
For every P2S VPN server configuration, one group must be selected as default. Users who present credentials that don't match any group settings are considered to be part of the default group. Once a group is created, the default setting of that group can't be changed.
Group priority
Each group is also assigned a numerical priority. Groups with lower priority are evaluated first. This means that if a user presents credentials that match the settings of multiple groups, they're considered part of the group with the lowest priority. For example, if user A presents a credential that corresponds to the IT Group (priority 3) and Finance Group (priority 4), user A is considered part of the IT Group for purposes of assigning IP addresses.
Available group settings
The following section describes the different parameters that can be used to define which groups members are a part of. The available parameters vary based on selected authentication methods. The following table summarizes the available setting types and acceptable values. For more detailed information on each type of Member Value, view the section corresponding to your authentication type.
| Authentication type | Member type | Member values | Example member value |
|---|---|---|---|
| Azure Active Directory | AADGroupID | Azure Active Directory Group Object ID | 0cf484f2-238e-440b-8c73-7bf232b248dc |
| RADIUS | AzureRADIUSGroupID | Vendor-specific Attribute Value (hexadecimal) (must begin with 6ad1bd) | 6ad1bd23 |
| Certificate | AzureCertificateID | Certificate Common Name domain name (CN=user@red.com) | red |
Azure Active Directory authentication (OpenVPN only)
Gateways using Azure Active Directory authentication can use Azure Active Directory Group Object IDs to determine which user group a user belongs to. If a user is part of multiple Azure Active Directory groups, they're considered to be part of the P2S VPN user group that has the lowest numerical priority.
However, if you plan to have users who are external (users who aren't part of the Azure Active Directory domain configured on the VPN gateway) connect to the point-to-site VPN gateway, make sure that the user type of the external user is "Member" and not "Guest". Also, make sure that the "Name" of the user is set to the user's email address. If the user type and name of the connecting user isn't set correctly as described above or you can't set an external member to be a "Member" of your Azure Active Directory domain, that connecting user will be assigned to the default group and assigned an IP from the default IP address pool.
You can also identify whether or not a user is external by looking at the user's "User Principal Name." External users have #EXT in their "User Principal Name."
Azure Certificate (OpenVPN and IKEv2)
Gateways that use Certificate-based authentication use the domain name of user certificate Common Names (CN) to determine which group a connecting user is in. Common Names must be in one of the following formats:
- domain/username
- username@domain.com
Make sure that the domain is the input as a group member.
RADIUS server (OpenVPN and IKEv2)
Gateways that use RADIUS-based authentication use a new Vendor-Specific Attribute (VSA) to determine VPN user groups. When RADIUS-based authentication is configured on the P2S gateway, the gateway serves as a Network Policy Server (NPS) proxy. This means that the P2S VPN gateway serves as a client to authenticate users with your RADIUS server using the RADIUS protocol.
After your RADIUS server has successfully verified the user's credentials, the RADIUS server can be configured to send a new Vendor-Specific Attribute (VSA) as part of Access-Accept packets. The P2S VPN gateway processes the VSA in the Access-Accept packets and assigns specific IP addresses to users based on the value of the VSAs.
Therefore, RADIUS servers should be configured to send a VSA with the same value for all users that are part of the same group.
Note
The value of the VSA must be an octet hexadecimal string on the RADIUS server and the Azure. This octet string must begin with 6ad1bd. The last two hexadecimal digits may be configured freely. For example, 6ad1bd98 is valid but 6ad12323 and 6a1bd2 would not be valid.
The new VSA is MS-Azure-Policy-ID.
The MS-Azure-Policy-ID VSA is used by the RADIUS server to send an identifier that is used by P2S VPN server to match an authenticated RADIUS user policy configured on Azure side. This policy is used to select the IP/ Routing configuration (assigned IP address) for the user.
The fields of MS-Azure-Policy-ID MUST be set as follows:
- Vendor-Type: An 8-bit unsigned integer that MUST be set to 0x41 (integer: 65).
- Vendor-Length: An 8-bit unsigned integer that MUST be set to the length of the octet string in the Attribute-Specific Value plus 2.
- Attribute-Specific Value: An octet string containing Policy ID configured on Azure point-to-site VPN server.
For configuration information, see RADIUS - configure NPS for vendor-specific attributes.
Gateway concepts
When a Virtual WAN P2S VPN gateway is assigned a VPN server configuration that uses user/policy groups, you can create multiple P2S VPN connection configurations on the gateway.
Each connection configuration can contain one or more VPN server configuration user groups. Each connection configuration is then mapped to one or more IP address pools. Users who connect to this gateway are assigned an IP address based on their identity, credentials, default group, and priority.
In this example, the VPN server configuration has the following groups configured:
| Default | Priority | Group name | Authentication type | Member value |
|---|---|---|---|---|
| Yes | 0 | Engineering | Microsoft Entra ID | groupObjectId1 |
| No | 1 | Finance | Microsoft Entra ID | groupObjectId2 |
| No | 2 | PM | Microsoft Entra ID | groupObjectId3 |
This VPN server configuration can be assigned to a P2S VPN gateway in Virtual WAN with:
| Configuration | Groups | Address pools |
|---|---|---|
| Config0 | Engineering, PM | x.x.x.x/yy |
| Config1 | Finance | a.a.a.a/bb |
The following result is:
- Users who are connecting to this P2S VPN gateway will be assigned an address from x.x.x.x/yy if they're part of the Engineering or PM Microsoft Entra groups.
- Users who are part of Finance Microsoft Entra group are assigned IP addresses from a.a.a.a/bb.
- Because Engineering is the default group, users who aren't part of any configured group are assumed to be part of Engineering and assigned an IP address from x.x.x.x/yy.
Configuration considerations
This section lists configuration requirements and limitations for user groups and IP address pools.
- The maximum number of groups that can be referenced by a single Point-to-site VPN Gateway is 90. The maximum number of policy/group members (criteria used to identify which group a connecting user is a part of) in groups assigned to a Gateway is 390. However, if a group is assigned to multiple connection configurations on the same Gateway, this group and its members are counted multiple times towards the limits. For example, if there's a policy group with 10 members that is assigned to three VPN connection configurations on the Gateway. This configuration would count as three groups with 30 total members as opposed to one group with 10 members. Note that the total number of concurrent users connecting to a gateway is limited by the gateway scale unit and the number of IP addresses allocated to each user group and not the number of policy/group members associated to a Gateway.
- Once a group has been created as part of a VPN server configuration, the name and default setting of a group can't be modified.
- Group names should be distinct.
- Groups that have lower numerical priority are processed prior to groups with higher numerical priority. If a connecting user is a member of multiple groups, the gateway will consider them to be a member of the group with lower numerical priority for purposes of assigning IP addresses.
- Groups that are being used by existing point-to-site VPN gateways can't be deleted.
- You can reorder the priorities of your groups by clicking on the up-down arrow buttons corresponding to that group.
- During the public preview, modifications of the VPN server configuration (for example, adding/removing members, changing priorities) aren't automatically propagated to the gateway. To ensure the gateway uses the latest version of the VPN server configuration, change the address pools associated to your VPN connection configurations.
- Address pools can't overlap with address pools used in other connection configurations (same or different gateways) in the same virtual WAN. Address pools also can't overlap with virtual network address spaces, virtual hub address spaces, or on-premises addresses.
Address pools can't overlap with address pools used in other connection configurations (same or different gateways) in the same virtual WAN.
Address pools also can't overlap with virtual network address spaces, virtual hub address spaces, or on-premises addresses.
Use cases
Contoso corporation is composed of multiple functional departments, such as Finance, Human Resources and Engineering. Contoso uses Azure Virtual WAN to allow remote workers (users) to connect to the virtual WAN and access resources hosted on-premises or in a virtual network connected to the virtual WAN hub.
However, Contoso has internal security policies where users from the Finance department can only access certain databases and virtual machines, and users from Human Resources have access to other sensitive applications.
Contoso can configure different user groups for each of their functional departments. This ensures users from each department are assigned IP addresses from a department-level predefined address pool.
Contoso's network administrator can then configure Firewall rules, network security groups (NSG) or access control lists (ACLs) to allow or deny certain users access to resources based on their IP addresses.
Next steps
- To create User Groups, see Create user groups for P2S User VPN.