--- title: 'Tutorial: Manage User and Group Properties from the Command Line' canonical: https://openvpn.net/as-docs/tutorials/tutorial--user-and-group-properties-cli/ product: Access Server Docs description: This tutorial provides information on managing user and group properties from the command line inside Access Server. --- # Tutorial: Manage User and Group Properties from the Command Line ## Overview When configuring Access Server for your needs, you can customize global properties for the entire server for all users and groups and set properties for specific users and groups. This tutorial describes these properties. In the example commands given in the documentation, **\** indicates where you can specify one of these: 1. A user name 2. A group name 3. \_\_DEFAULT\_\_ > **Tip** > > **How to use \_\_DEFAULT\_\_** > > You can use **\_\_DEFAULT\_\_** (two underscores on both sides of the capitalized word, DEFAULT) as a special, reserved keyword. When you define a property for \_\_DEFAULT\_\_, other users and groups can inherit the defined property. Existing and new user or group accounts can assume certain properties. An example would be the ability to use auto-login-type [connection profiles](https://openvpn.net/as-docs/connection-profiles.md). ## Prerequisites - An installed Access Server. - Console access with root privilege. - Configured users (and groups). > **Important** > > **Important notes about the commands below** > > - Ensure you use single quotes (') around the \ instead of double quotes (") if you specify passwords on the command line that have unique characters in them with special meaning on the command line—such as the $ character (variable). > - If you set a property for a user that doesn’t exist, the result of the command is to create the user and set the property. Thus, if, for example, you set the auto-login property (prop\_autologin) either false or true on a user that doesn’t exist, then the user will automatically exist from that point on. To authenticate, the user must also exist in the authentication system, and it depends on your chosen authentication system to set up a password and possibly an account for that user. > - Properties work with inheritance. For example, if you enable the auto-login property on a group, users in that group inherit the privilege to download an auto-login type configuration file. Suppose you specifically deny the auto-login property on a user in that group. In that case, users in that group can get an auto-login type configuration file, except for that user. If neither the user nor the group has anything specified in the auto-login property, then it will be inherited from **\_\_DEFAULT\_\_**, which by default has the value "false". > - Groups need a subnet to work with. It can either be a global subnet you configure in the **VPN Settings** page or the server's global configuration database, or a subnet you define specifically for the group. Without a valid subnet from which to draw IP addresses, users assigned to a group tend to end up with one of the standard addresses from the globally configured dynamic IP address pool. > - Many commands with the **sacli** tool write changes to the configuration databases that store all the settings but may not take effect immediately. You must refresh the running servers with the **sacli** start command, and changes will be effective. This command only refreshes or restarts components that need it. Additionally, suppose you make changes that may require a connected user to be disconnected and reconnected. In that case, the Access Server may issue a 'kick' command to such a connected client, forcing it to disconnect and reconnect and obtain the correct settings from the server. ## View current user and group properties The following commands are common tasks for managing user and group properties from the command-line interface. 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Run commands below for your needs: - Show the current properties for all users: ``` ./sacli UserPropGet ``` - Show the current properties for a specific user or group: ``` ./sacli --pfilt UserPropGet ``` - Remove all properties (this deletes the user or group): ``` ./sacli --user UserPropDelAll ``` - Refresh the Access Server configuration: ``` ./sacli start ``` ## Manage auto-login privileges and profiles 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Run commands below for managing auto-login privileges: - Enable the auto-login privilege for a user or group: ``` ./sacli --user --key "prop_autologin" --value "true" UserPropPut ``` - Disable or revoke the auto-login privilege for a user or group: ``` ./sacli --user --key "prop_autologin" --value "false" UserPropPut ``` - Remove the auto-login property from a user or group: ``` ./sacli --user --key "prop_autologin" UserPropDel ``` - Refresh the Access Server configuration: ``` ./sacli start ``` 4. Run these commands for defining auto-login connection profiles: - Allow all users in a group to use auto-login connection profiles: ``` ./sacli --user --key "prop_autologin" --value "true" UserPropPut ``` - Allow all users to use auto-login connection profiles by default: ``` ./sacli --user "__DEFAULT__" --key "prop_autologin" --value "true" UserPropPut ``` - Deny all users' auto-login connection profiles: ``` ./sacli --user "__DEFAULT__" --key "prop_autologin" UserPropDel ``` - Restore to default and have it adhere to any inheritance: ``` ./sacli --user --key "prop_autologin" UserPropDel ``` - Refresh the Access Server configuration: ``` ./sacli start ``` > **Note** > > Auto-login connection profiles allow automatic connection without requiring user input. This means this connection profile contains everything it needs to make a connection: a user-unique, embedded client certificate and private key known at the Access Server as being allowed to make a connection in this way. > > You can set the **prop\_autologin** property on the **\_\_DEFAULT\_\_** pseudo name, a group name, or a user name, and it can be inherited. Access Server doesn't have the **prop\_autologin** property defined anywhere by default, and it is then assumed to be denied. ## Create users and groups 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Use the commands below to create new users and groups: - Add a new user from scratch: ``` ./sacli --user --key "type" --value "user_connect" UserPropPut ``` - Create a new group from scratch: ``` ./sacli --user --key "type" --value "group" UserPropPut ./sacli --user --key "group_declare" --value "true" UserPropPut ``` - Add a user to a group: ``` ./sacli --user --key "conn_group" --value UserPropPut ``` - Remove a user from a group: ``` ./sacli --user --key "conn_group" UserPropDel ``` - Refresh the Access Server configuration: ``` ./sacli start ``` ## Work with passwords 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Use the commands below for setting passwords: - Set the password for a user in local authentication mode: ``` sacli --user '' --new_pass '' SetLocalPassword sacli start ``` - Remove password for a user in local authentication mode: ``` ./sacli --user '' RemoveLocalPassword ./sacli start ``` - Change the minimum password length when password strength checking is enabled (the default is 8): ``` ./sacli --key "auth.local.0.min_len" --value "" ConfigPut ./sacli start ``` ## Set authentication methods 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Use the commands below for managing users' and groups' authentication methods: > **Important** > > Ensure you configure RADIUS, LDAP, or SAML authentication if assigned to a user or group. - Assign an authentication method to a user: ``` ./sacli --user --key "user_auth_type" --value "" UserPropPut ``` Where **\** can have these values: - local - pam - radius - ldap - saml - Assign an authentication method to a group: ``` ./sacli --user --key "user_auth_type" --value "" UserPropPut ``` Where **\** can have these values: - local - pam - radius - ldap - saml - Refresh the Access Server configuration: ``` ./sacli start ``` ## Configure IP addresses ### Define a subnet To assign a user a static IP address, you must first configure a static IP address network. By default, Access Server uses dynamic IP addresses. Depending on your configuration, you must configure a subnet at either the global or group level. > **Important** > > It helps to understand the following for configuring subnets: > > 1. All subnets you use must be unique, so when you configure a subnet, ensure it’s different from anything else you have. > 2. For IP addresses on the subnet, it’s important to know that Access Server uses the start IP address and the end IP address for itself. For example, with the subnet 198.51.100.0/24, Access Server uses 198.51.100.1 and 198.51.100.254. You can’t use these for your user’s static IP address assignment. Valid addresses are 198.51.100.2 through 198.51.100.253. > > > **Note** > > > > In our documentation, we use example IPv4 addresses and subnets [reserved for documentation](https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4), such as `192.0.2.0/24`, `198.51.100.0/24`, and `203.0.113.0/24`. > > > > Ensure you replace them with valid IPv4 addresses and subnets for your network(s). > 3. Access Server uses IP addresses more efficiently when you configure groups with subnets rather than a global static IP addressing space. This is because IP addressing and access control work internally, creating a certain 'waste' of IP addressing space. It’s possible that Access Server can run out of assignable addresses even though your clients haven’t used the entire subnet. However, since millions of IP addresses are in private IP address space, this should not pose any problems. > 4. In the commands below, if we assume we want to configure 198.51.100.0/24 as the subnet to use, then **SUBNET** is 198.51.100.0, and **CIDR** is 24. In the case of **SUBNET/CIDR**, you write it as 198.51.100.0/24. #### Define a global subnet You can define a global subnet if none of your users are assigned to groups. You can set it from the **VPN Settings** page in the Admin Web UI or with the following commands. 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Assign a global, default static IP addressing network: ``` ./sacli --key "vpn.server.static.0.network" --value ConfigPut ./sacli --key "vpn.server.static.o.netmask_bits" --value ConfigPut ``` - You can now jump down to the [instructions for assigning a user a static IP address](https://openvpn.net/as-docs/tutorials/tutorial--user-and-group-properties-cli/#assign-a-user-a-static-ip-address). #### Define a subnet for users not part of a group If you have some users in groups, but the user you want to assign a static IP address to isn't part of one, the default **static IP address network** configured in the Admin Web UI under **VPN Settings** is used. 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Assign a default static IP addressing network for users not part of a group: ``` ./sacli --key "vpn.server.static.0.network" --value ConfigPut ./sacli --key "vpn.server.static.o.netmask_bits" --value ConfigPut ``` - You can now jump down to the [instructions for assigning a user a static IP address](https://openvpn.net/as-docs/tutorials/tutorial--user-and-group-properties-cli/#assign-a-user-a-static-ip-address). #### Define a group subnet If the user you want to assign a static IP address to is part of a group, the static IP address you assign to the user must fall within the subnet of the assigned group. If the group doesn't have a subnet yet, you must assign it first to use static IP addressing on a user in a group. For groups without defined subnets, Access Server dynamically allocates IP addresses to your users from the **Group Default IP Address Network (optional)** configured in the Admin Web UI under **VPN Settings**. To switch a user over to a static IP address, you must assign a subnet to the user’s group. Such a subnet is only for static assignment and forces all users in the group to use IP addresses from the group subnet. There are two subnet fields under a group’s “More Settings” in the Admin Web UI: 1. Subnets assigned to this group. 2. Dynamic subnet ranges for this group. You define the subnet for the static IP address assignment in the first field. The second field specifies a dynamic allocation range for users in a group that doesn't get a static IP address assigned. 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Assign a primary subnet for static IP addressing space to a group: ``` ./sacli --user --key "group_subnets.0" --value UserPropPut ``` - You can now jump down to the [instructions for assigning a user a static IP address](https://openvpn.net/as-docs/tutorials/tutorial--user-and-group-properties-cli/#assign-a-user-a-static-ip-address). #### Assign a user a static IP address Now that you have a subnet defined—either globally or at the group level—you can assign your user a static IP address. 1. Assign a user a static IP address: ``` ./sacli --user --key "conn_ip" --value UserPropPut ``` ## Manage access control rules Access control rules, or access control lists (ACLs), allow you to specify which IP addresses or subnets users and groups can access through the VPN. Access Server enforces these rules through firewall rules, automatically pushing relevant routes to VPN clients based on configured access control rules, ensuring that no unauthorized traffic passes through. - **NAT Method:** When using NAT (Network Address Translation), traffic appears to come from the Access Server. This method doesn’t require any special routing configurations on the target network. - **Routing Method:** When using routing, the VPN client's IP address is exposed to the network. You must configure the target network to route traffic back to the VPN client through Access Server as the gateway. This is typically done using (static) routes in your network. ### Applying access control You can apply [ACLs at different levels](https://openvpn.net/as-docs/access-control.md): - **Global Settings:** Applied to all users. - **Group Level:** Applied to specific user groups. - **User Level:** Applied to individual users. Rules applied at different levels are additive, meaning users will inherit access control rules from global, group, and user-specific settings. > **Important** > > Access control rules can't be applied to the **\_\_DEFAULT\_\_** meta user. ### Command-line management of ACLs > **Note** > > Access control rules are specified using the **access\_to.n** key, where n must be a number starting at 0. Access Server is smart enough to accept numbers out of order to make automation more manageable, such as '999.' It can also take items removed from the middle of an ACL and automatically correct the ordering to make it a contiguous, sequential list with no gaps. You can manage ACLs via the command line using the [sacli command-line tool](https://openvpn.net/as-docs/tutorials/tutorial--sacli-command-line-tool.md). For steps on managing ACLs from the Admin Web UI, refer to these tutorials: - [Tutorial: How to Configure Global Access Control](https://openvpn.net/as-docs/tutorials/tutorial--global-access-control.md) - [Tutorial: How to Configure Group Access Control](https://openvpn.net/as-docs/tutorials/tutorial--group-access-control.md) - [Tutorial: How to Configure User Access Control](https://openvpn.net/as-docs/tutorials/tutorial--user-access-control.md) 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Use these commands for common configurations: - **Grant access to a single IP using NAT:** ``` ./sacli --user --key "access_to.0" --value "+NAT:192.0.2.100/32" UserPropPut ``` - **Grant access to a single IP using routing:** ``` ./sacli --user --key "access_to.0" --value "+ROUTE:192.0.2.100/32" UserPropPut ``` - **Grant access to a range of IP addresses (subnet) using NAT:** ``` ./sacli --user --key "access_to.0" --value "+NAT:192.0.2.0/24" UserPropPut ``` - **Grant access to a range of IP addresses (subnet) using routing:** ``` ./sacli --user --key "access_to.0" --value "+ROUTE:192.0.2.0/24" UserPropPut ``` - **Grant access to TCP port 443 on a specific IP using NAT:** ``` ./sacli --user --key "access_to.0" --value "+NAT:192.0.2.100:tcp/443" UserPropPut ``` - **Example: specifying multiple access control rules:** ``` ./sacli --user --key "access_to.0" --value "+NAT:192.0.2.0/24" UserPropPut ./sacli --user --key "access_to.1" --value "+ROUTE:198.51.100.0/24" UserPropPut ./sacli --user --key "access_to.2" --value "+NAT:203.0.113.1:tcp/443" UserPropPut ``` ## Disconnect (kick) a user If you need to force a user to drop its Access Server connection, you can do so using the `sacli DisconnectUser` function. With this function, you can: 1. Kick a user off the server. 2. Send a text string to the VPN client, which will display on the screen or in the log, and explain why the user was kicked off the server. 3. Kick a user off the server with an invitation to reconnect with their existing session token. > **Caution** > > If a user has multiple active OpenVPN tunnels, it is impossible to specify a single VPN tunnel for that user to kick; it's all or nothing. 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Use these commands for disconnecting users: - Disconnect all VPN connections for a given user name: ``` ./sacli --user DisconnectUser ``` - Disconnect all VPN connections for a given user name with a reason: ``` ./sacli --user --client_reason DisconnectUser ``` - Disconnect all VPN connections for a given user name with an invitation to auto-reconnect: ``` ./sacli --user --restart --psid DisconnectUser ``` When you provide text parameters to the **sacli** command, such as the **--client-reason**, ensure you enclose it with double quotes. For example, "You have been disconnected by sysadmin". Spaces tend to upset command line programs, but enclosing a text string with double quotes works correctly. Some clients and configurations attempt to reconnect automatically, regardless of the method used to disconnect a user from the VPN server. If you want the user to stay disconnected in such a situation, you can additionally set the **prop\_deny** property on the user to true. This effectively bans the user from the server. See below for this. ## Block (ban) a user With the **prop\_deny** property, you can deny access to users. You can lift this restriction at any time. You can set this property on a user name, a group name, or the pseudo name **\_\_DEFAULT\_\_**, and it can be inherited. The user still exists with Access Server with all its settings and certificates retained, but they can’t sign in to the web services or connect to the VPN. If the user has a current VPN connection, then banning the user doesn’t disconnect them, but only prevents them from making a new connection or signing in to the web interface. You can kick any existing connections using the `sacli DisconnectUser` function (above). 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Use these commands for blocking users or groups: - Deny future logins for a user or group: ``` ./sacli --user --key "prop_deny" --value "true" UserPropPut ``` - Specifically, allow future logins for a user or group: ``` ./sacli --user --key "prop_deny" --value "false" UserPropPut ``` - Restore to default and have it adhere to any inheritance: ``` ./sacli --user **Tip** > > We recommend the following due to possible issues with access control: > > - Assigning normal users to normal groups and admin users to admin groups. > - Avoid mixing admin users in normal groups or normal users in admin groups. > > Access Server can then choose the safe path and deny access to certain subnets rather than giving normal users access to subnets that should only be accessible to admin users, for example. 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Use these commands for setting admin privileges: - To grant a user or group admin privileges: ``` ./sacli --user --key "prop_superuser" --value "true" UserPropPut ``` - To specifically revoke admin privileges for a user or group: ``` ./sacli --user --key "prop_superuser" --value "false" UserPropPut ``` - Restore to default and have it adhere to any inheritance: ``` ./sacli --user --key "prop_superuser" UserPropDel ``` ## Set compression settings > **Important** > > Access Server doesn’t have compression enabled by default. For more information, refer to the security advisory about [the VORACLE attack vulnerability](https://openvpn.net/security-advisory/the-voracle-attack-vulnerability/). We recommend turning off compression for VPN connections. In the Admin Web UI under **Advanced VPN**, you can enable or disable compression support. Depending on the circumstances and data transferred, compression support can enhance the connection speed, and in most cases, it positively impacts the transfer speed. You can enable or disable it globally and still override it specifically for users or groups using the **prop\_force\_lzo** property shown in the examples below. This doesn’t limit Access Server to using only the LZO compression method, but the property name is just a holdover from when LZO was the only compression method available in OpenVPN at the time. If you delete the property from the user or group, it will adhere to the global default set under **Advanced VPN** in the Admin Web UI. 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Set compression settings with these commands: - Enable compression for a given user or group: ``` ./sacli --user --key "prop_force_lzo" --value "true" UserPropPut ``` - Disable compression for a given user or group: ``` ./sacli --user --key "prop_force_lzo" --value "false" UserPropPut ``` ## Manage redirect-gateway and DNS settings. Redirect-gateway is the directive name in the OpenVPN protocol that instructs a VPN client to send all its traffic through the VPN tunnel to the VPN server. In the Admin Web UI under **VPN Settings**, you can configure connected VPN clients to send internet traffic through Access Server globally, and configure pushing DNS servers to the VPN clients. Usually, both are done to ensure DNS queries can be resolved, as some providers block queries to their DNS servers from non-local sources. It can be explicitly overridden for users or groups using the **prop\_reroute\_gw\_override** property shown in the examples below. If you delete the property from the user or group, it adheres to the global defaults set under **VPN Settings**. It’s impossible to push a specific DNS server to a specific user or group. The DNS servers that are pushed are set globally, and only the act of pushing them to a user or group can be switched on or off. Additionally, suppose you want to redirect client internet traffic through Access Server without implementing DNS for a specific user or group. In that case, you can use the trick of turning off the option to redirect client internet traffic through the server in the **VPN Settings** page, and then go to the settings for that user or group and give access via NAT method to the subnets 0.0.0.0/1 and 128.0.0.0/1. 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Use these commands for configuring redirect-gateway and DNS server settings: - Disable redirection of internet traffic, and don’t push DNS servers: ``` ./sacli --user --key "prop_reroute_gw_override" --value "disable" UserPropPut ``` - Disable redirection of internet traffic, but still push DNS servers: ``` ./sacli --user --key "prop_reroute_gw_override" --value "dns_only" UserPropPut ``` - Use the settings as defined under **VPN settings** , specifically: ``` ./sacli --user --key "prop_reroute_gw_override" --value "global" UserPropPut ``` - Restore to default and have it adhere to any inheritance: ``` ./sacli --user --key "prop_reroute_gw_override" UserPropDel ``` - Redirect internet traffic for a user, but don’t change DNS settings: ``` ./sacli --user --key "type" --value "user_compile" UserPropPut ./sacli --user --key "access_to.0" --value "+NAT:0.0.0.0/1" UserPropPut ./sacli --user --key "access_to.1" --value "+NAT:128.0.0.0/1" UserPropPut ``` - Redirect internet traffic for a group, but don’t change DNS settings: ``` ./sacli --user --key "access_to.0" --value "+SUBNET:0.0.0.0/1" UserPropPut ./sacli --user --key "access_to.1" --value "+SUBNET:128.0.0.0/1" UserPropPut ``` > **Note** > > In the last two examples, where `0.0.0.0/1` and `128.0.0.0/1` subnets are used to simulate full internet routing, the examples assume there are no other access rules already assigned to the user or group. If additional access rules exist, use the next available configuration key index (e.g., `.2`, `.3`, `.4`, and so on) when adding rules via the command line. > > The Admin Web UI supports mixing NAT and Route rules by defining private subnets for routing on the **Advanced VPN** page using the **Private Routed Subnets** field. > > You may also see the `user_compile` property associated with a user. By default, when a user has no custom access rules, the property `user_connect` is used. This means the user joins the VPN client subnet without requiring custom routing setup. When you assign specific access rules, Access Server switches to using the `user_compile` property to instruct the server to apply custom network rules for the user during connection. ## Create a bypass or exclusion route Sometimes, people want to bypass or exclude a specific IP address or subnet. For example, you might want to redirect all VPN client internet traffic through the VPN server, except for a specific IP address or range of IP addresses that you want to remain on the client side and not be sent through the VPN tunnel. The OpenVPN protocol does this by sending a route directive with a specific **route** subnet, but then specifies the keyword **net\_gateway**, translated on the client-side as the default gateway address. Such a directive is pushed from the server and looks like this on the client side: - **route 192.51.100.0 255.255.255.0 net\_gateway** In the mentioned example, where all client internet traffic is being rerouted, except for the subnet just mentioned above, the routing table on the client side looks like this: - **0.0.0.0/0** — goes to the local default gateway on the VPN client. - **0.0.0.0/1** and **128.0.0.0/1** — goes to the VPN server subnet gateway address. - **192.51.100/24** — goes to the local default gateway on the VPN client side. - **192.0.2.0/24** — stays on the VPN client's local network; the VPN client is a part of this network. Since with routing the smallest subnet, or better put, the most specific route, will win, the result is that internet-directed traffic goes through the 0.0.0.0/1 and 128.0.0.0/1 routes since they 'win' over the default 0.0.0.0/0 route, and 192.51.100.0/24 will go to the local default gateway on the VPN client side and not through the VPN tunnel, and 192.0.2.0/24 is the subnet that the VPN client was already on even before connecting to OpenVPN, so that traffic also remains local, unless you were to specifically override it with rules like 192.0.2.0/25 and 192.0.2.128/25 (not recommended). 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Create a bypass route: ``` ./sacli --user --key "bypass_route.N" --value UserPropPut ./sacli start ``` The **bypass\_route.N** is a logically numbered range starting with 0 and going up sequentially. If you leave gaps in the sequence, Access Server may not pick up all the subnets correctly, and you must ensure they're numbered right. The subnet can be a single IP such as 203.0.113.10/32 or a range such as 192.0.2.0/24. You can create the bypass route on a user, group, or global level, by using either the user name, the group name, or the **\_\_DEFAULT\_\_** meta user name, where **\** is shown in the above example. 4. Define multiple subnets by numbering **bypass\_route.N** logically, for example: ``` ./sacli --user --key "bypass_route.0" --value "192.168.25.0/24" UserPropPut ./sacli --user --key "bypass_route.1" --value "10.0.44.54/32" UserPropPut ./sacli --user --key "bypass_route.2" --value "123.45.67.89/32" UserPropPut ./sacli start ``` ## Block local access to client-side LAN The server can send a directive to the OpenVPN client to instruct it to block access to the LAN network. The exception is the local internet gateway, and any more specific routes for the local network in the routing table. OpenVPN detects the local network and routes traffic for this network into the VPN tunnel. You can set this block on a user, group, or global level, by using either the user name, the group name, or the **\_\_DEFAULT\_\_** meta username, where **\** is shown in the example below. 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Turn on the local network block: ``` ./sacli --user --key "prop_block_local" --value "true" UserPropPut ./sacli start ``` 4. Restore to default and have it adhere to any inheritance: ``` ./sacli --user --key "prop_block_local" UserPropDel ``` ## Specify a client-side script In the Admin Web UI, you're limited to specifying a client-side script on a group and then assigning users to those groups. There is no more granularity than that for client-side scripting. However, on the command line, you can set a script on a **user**, **group**, or the **\_\_DEFAULT\_\_** special keyword from which the default properties for users and groups are inherited. 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Use the following commands for specifying client-side script options: - Load an on-connect client-side script for Windows: ``` ./sacli --user --key "prop_cli.script.win.user.connect" --value_file "./windows-on-connect.txt" UserPropPut ``` - Load an on-connect client-side script for macOS: ``` ./sacli --user --key "prop_cli.script.mac.user.connect" --value_file "./macintosh-on-connect.txt" UserPropPut ``` - Load an on-connect client-side script for Linux: ``` ./sacli --user --key "prop_cli.script.linux.user.connect" --value_file "./linux-on-connect.txt" UserPropPut ``` - Load an on-connect client-side script for all three platforms: ``` ./sacli --user --key "prop_cli.script.all.user.connect" --value_file "./all-on-connect.txt" UserPropPut ``` - Remove an on-connect client-side script of the four types shown above—note that this does not stop inheriting scripts from a higher level: ``` ./sacli --user --key "prop_cli.script.win.user.connect" UserPropDel ./sacli --user --key "prop_cli.script.mac.user.connect" UserPropDel ./sacli --user --key "prop_cli.script.linux.user.connect" UserPropDel ./sacli --user --key "prop_cli.script.all.user.connect" UserPropDel ``` - Load an on-disconnect client-side script for Windows: ``` ./sacli --user --key "prop_cli.script.win.user.disconnect" --value_file "./windows-on-disconnect.txt" UserPropPut ``` - Load an on-disconnect client-side script for macOS: ``` ./sacli --user --key "prop_cli.script.mac.user.disconnect" --value_file "./macintosh-on-disconnect.txt" UserPropPut ``` - Load an on-disconnect client-side script for Linux: ``` ./sacli --user --key "prop_cli.script.linux.user.disconnect" --value_file "./linux-on-disconnect.txt" UserPropPut ``` - Load an on-disconnect client-side script for all three platforms: ``` ./sacli --user --key "prop_cli.script.all.user.disconnect" --value_file "./all-on-disconnect.txt" UserPropPut ``` - Remove an on-disconnect client-side script of the four types shown above—note that this does not stop inheriting scripts from a higher level: ``` ./sacli --user --key "prop_cli.script.win.user.disconnect" UserPropDel ./sacli --user --key "prop_cli.script.mac.user.disconnect" UserPropDel ./sacli --user --key "prop_cli.script.linux.user.disconnect" UserPropDel ./sacli --user --key "prop_cli.script.all.user.disconnect" UserPropDel ``` ## Set a client-side environment variable You can set a client-side environment variable in the Admin Web UI for a group, but, in the command line, you can set it per group or user individually. You can push variables to the client program, which is available to the client-side script, as specified in the section above. 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Set a client-side environment variable: ``` ./sacli --user --key "prop_cli.script_env.win.username" --value "john" UserPropPut ``` In this example, we're setting the "username" variable. We set the "username" to "john" on the client. > **Tip** > > As with client-side scripting, you can adjust the "win" to "mac", "linux", or "all", to specify if this should apply to Windows, macOS, Linux, or all three of them. In the above example, the key name contains the variable's name. So if you want to specify a variable name "myvariable" then change "username" to "myvariable" in the above example. 4. Remove the variable setting shown above: ``` ./sacli --user --key "prop_cli.script_env.win.username" UserPropDel ``` ## Evaluate specific directives for a user/group > **Important** > > This is an unsupported feature, but it can be helpful in very rare cases where you have a device that needs some particular instructions that normally should not be necessary and might actually cause problems for other devices. You don't want to affect other users and groups with such specific settings. This allows adding server-side OpenVPN directives that apply only to specific users or groups. 1. Connect to the console and get root privileges. 2. Switch to the scripts directory: ``` cd /usr/local/openvpn_as/scripts/ ``` 3. Set specific server-side directives for a user or group: ``` ./sacli --user --key "prop_cc_cmds" --value 'compress lz4-v2,push "compress lz4-v2"' UserPropPut ``` 4. Remove the specific directive: ``` ./sacli --user --key "prop_cc_cmds" UserPropDel ``` --- Prev: [User and IPv6 Configuration](https://openvpn.net/as-docs/tutorials/user-and-ipv6-configuration.md) Next: [Tutorial: Assign Public IPv6 IP Addresses to VPN Clients](https://openvpn.net/as-docs/tutorials/tutorial--assign-ipv6-addresses.md) Index: https://openvpn.net/as-docs/llms.txt