Skip to main content

OpenVPN Support Center

Welcome to the new and improved OpenVPN Support Center.

Search the Support Center

Access Server: Configure Access Rules based on Group Permissions

  • Updated

Description: Access Server allows you to configure access rules at the global, group, and user levels. This article explains how to configure access rules based on group permissions, which follow a slightly different logic than global or user rules.

You can configure group access rules using the Admin Web UI or the command-line interface (CLI).

For the examples here, we use the following:

  • VPN client IP: 192.0.2.15
  • Destination IP: 203.0.113.182
  • Group name: Brandon-Test

Use network address translation (NAT) for group access rules

Access Server uses the +SUBNET directive to apply group-based access control. This method performs NAT, replacing the client IP with Access Server's internal IP.

You can configure this in either the Admin Web UI or CLI.

Turn on access control for your group in the Admin Web UI:

  1. Sign in to the Admin Web UI.
  2. Click User Management > Group Permissions.
  3. Next to your group (e.g., Brandon-Test), click the icon for More Settings.
  4. Set Use Access Control to Yes.
  5. Enter the subnet IP address for your destination (e.g., 203.0.113.182/32) in Allow Access To networks and services. 
  6. Click Save and Update Running Server.
    group-access-control.jpg

Turn on access control for your group in the CLI:

  1. Open the console session and run sudo su.
  2. Switch to the scripts directory. 
    cd /usr/local/openvpn_as/scripts
  3. Run the command to apply the access rule: 
    ./sacli --user "Brandon-Test" --key "access_to.0" --value "+SUBNET:203.0.113.182/32" UserPropPut
  4. Restart Access Server: 
    ./sacli start

How it works (with NAT)

When Access Server uses +SUBNET, it performs NAT. This masks and replaces the client's IP with the server's internal IP.

Example packet flow:

11:37:23.658612 In ethertype IPv4 (0x0800), length 76: 192.0.2.15 > 203.0.113.182: ICMP echo request, id 1, seq 2, length 40
11:37:23.658656 Out XXXXX ethertype IPv4 (0x0800), length 76: 203.0.113.190 > 203.0.113.182: ICMP echo request, id 1, seq 2, length 40
11:37:23.659555 In XXXXX ethertype IPv4 (0x0800), length 76: 203.0.113.182 > 203.0.113.190: ICMP echo reply, id 1, seq 2, length 40
11:37:23.659582 Out ethertype IPv4 (0x0800), length 76: 203.0.113.182 > 192.0.2.15: ICMP echo reply, id 1, seq 2, length 40

Result: Traffic appears to originate from Access Server's internal IP (203.0.113.190) instead of the client IP (192.0.2.15).

ℹ️ When you configure group access rules, the +SUBNET directive is required. You cannot use +NAT or +ROUTE—they will be overwritten by +SUBNET.

Example:

"Brandon-Test": {
 "access_to.0": "+SUBNET:203.0.113.182/32",

Important note about global access interaction

When you configure group access rules, those permissions are added on top of any global access control rules you've enabled.

For example, if a group is granted access to 203.0.113.182/32, and there's also a global rule that allows access to 198.51.100.100/32, then users in that group can reach both destinations.

global-routing-2nd-route.jpg

If your goal is to restrict access strictly to what's defined by the group, you must disable global access control rules:

  1. Sign in to the Admin Web UI.
  2. Click Configuration > VPN Settings > Routing.
  3. Set Should VPN clients have access to private subnets? to No.

This ensures users only have access to the resources explicitly allowed in the group's access rules.

routing-turned-off.jpg

Use routing for group access rules

If you prefer to preserve the original VPN client IP (i.e., no NAT), you can configure routing instead.

To enable routing, you must still use the +SUBNET directive but combine it with global or advanced routing settings. You have two options:

Option 1: Inherit route from global settings

Admin Web UI

  1. Sign in to the Admin Web UI.
  2. Click User Management > Group Permissions.
  3. Next to your group (e.g., Brandon-Test), click the icon for More Settings.
  4. Set Use Access Control to Yes.
  5. Enter the subnet IP address for your destination (e.g., 203.0.113.182/32) in Allow Access To networks and services. 
  6. Click Save and Update Running Server.
    group-access-control.jpg
  7. Click Configuration > VPN Settings > Routing.
  8. Click Yes, using Routing to turn on routing globally.
  9. Enter 203.0.113.182/32 under Specify private subnets to which all clients should be given access.
  10. Click Save Settings and Update Running Server.
    global-routing.jpg

CLI

  1. Open the console session and run sudo su.
  2. Switch to the scripts directory. 
    cd /usr/local/openvpn_as/scripts
  3. Configure the group rule: 
    ./sacli --user "Brandon-Test" --key "access_to.0" --value "+SUBNET:203.0.113.182/32" UserPropPut
  4. Add the global route: 
    ./sacli --key "vpn.server.routing.private_network.0" --value "203.0.113.182/32" ConfigPut
  5. Restart Access Server: 
    ./sacli start

Result with routing (no NAT)

Example packet flow:

12:06:41.249084 In ethertype IPv4 (0x0800), length 76: 192.0.2.15 > 203.0.113.182: ICMP echo request, id 1, seq 5, length 40
12:06:41.249139 Out XXXXX ethertype IPv4 (0x0800), length 76: 192.0.2.15 > 203.0.113.182: ICMP echo request, id 1, seq 5, length 40
12:06:41.251632 In XXXXX ethertype IPv4 (0x0800), length 76: 203.0.113.182 > 192.0.2.15: ICMP echo reply, id 1, seq 5, length 40
12:06:41.251660 Out ethertype IPv4 (0x0800), length 76: 203.0.113.182 > 192.0.2.15: ICMP echo reply, id 1, seq 5, length 40

Result: Routing preserves the original client IP (192.0.2.15).

Option 2: User private routed subnets (no changes to global routing)

This method is useful if global routing is set to NAT and you want routing only for specific groups.

Admin Web UI

  1. Sign in to the Admin Web UI.
  2. Click User Management > Group Permissions.
  3. Next to your group (e.g., Brandon-Test), click the icon for More Settings.
  4. Set Use Access Control to Yes.
  5. Enter the subnet IP address for your destination (e.g., 203.0.113.182/32) in Allow Access To networks and services. 
  6. Click Save and Update Running Server.
    group-access-control.jpg
  7. Click Configuration > Advanced VPN > Private Routed Subnets (Optional).
  8. Add 203.0.113.182/32.
  9. Click Save Settings and Update Running Server.
    private-routed-subnets.jpg

CLI

  1. Open the console session and run sudo su.
  2. Switch to the scripts directory. 
    cd /usr/local/openvpn_as/scripts
  3. Configure the group rule: 
    ./sacli --user "Brandon-Test" --key "access_to.0" --value "+SUBNET:203.0.113.182/32" UserPropPut
  4. Add the routed subnet:
    ./sacli --key "vpn.server.routing.routed_subnets.0" --value "203.0.113.182/32" ConfigPut
  5. Restart Access Server: 
    ./sacli start

Result with routed subnet (no NAT)

Example packet flow:

12:16:49.686524 In ethertype IPv4 (0x0800), length 76: 192.0.2.15 > 203.0.113.182: ICMP echo request, id 1, seq 9, length 40
12:16:49.686576 Out XXXXX ethertype IPv4 (0x0800), length 76: 192.0.2.15 > 203.0.113.182: ICMP echo request, id 1, seq 9, length 40
12:16:49.688884 In XXXXX ethertype IPv4 (0x0800), length 76: 203.0.113.182 > 192.0.2.15: ICMP echo reply, id 1, seq 9, length 40
12:16:49.688912 Out ethertype IPv4 (0x0800), length 76: 203.0.113.182 > 192.0.2.15: ICMP echo reply, id 1, seq 9, length 40

Result: The VPN client IP is preserved, and the traffic arrives, using "192.168.100.15" in the ingress packet, and then we see "192.168.100.15" again as Source IP in the Egress Packet. Access Server is performing ROUTE (No NAT to the internal Access Server IP).

 

If you have additional questions, please submit a ticket.

Comments

0 comments

Please sign in to leave a comment.