Tutorial: Manage User and Group Properties from the Command Line

The following commands are common tasks for managing user and group properties from the command-line interface.

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.

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:

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.

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).

By default, unlisted accounts are denied access.

Admin privileges grant a user access to access the Admin Web UI for Access Server. We recommend you give admin privileges only for the administration of Access Server. While you can use user accounts with admin privileges for VPN connections, they may have special access to configured subnets that can disrupt the inheritance of properties from groups, like access control rules. So if you experience a problem where an admin user in a normal group doesn’t receive certain routes or access to specific subnets, that may be why.

In Access Server versions prior to 3.0, you could enable or disable compression globally from the Advanced VPN section of the Admin Web UI. In version 3.0 and newer, compression settings are no longer available in the UI, but they can still be configured using the command line.

You can manage compression behavior per user or group using the prop_force_lzo property, as shown in the examples below. This allows you to override the global compression setting, or define compression behavior manually if no global setting exists.

If you remove the prop_force_lzo property from a user or group, compression behavior will follow the global configuration if one has been defined via the command line.

In the OpenVPN protocol, the redirect-gateway directive tells a VPN client to send all internet traffic through the VPN tunnel. In Access Server 3.0 and newer, you can manage this setting in the Access Controls page under the Internet Access and DNS tab.

The Internet Gateway setting determines whether connected VPN clients route all traffic through the VPN (Full-Tunnel) or only access specified internal resources (Split-Tunnel). To ensure DNS resolution works correctly in full-tunnel mode, you can enable the Push DNS option and choose either Autodetect (uses the server’s system DNS settings) or Custom (manually specify one or more DNS server IP addresses).

The global internet gateway and DNS push settings apply to all clients by default. You can override the redirect-gateway behavior for individual users or groups using the prop_reroute_gw_override property from the command line. Removing this property causes the user or group to fall back to the global tunnel setting.

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:

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:

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).

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 <USERNAME> is shown in the example below.

You can set a client-side environment variable in the Admin Web UI on the single group page via the Client Scripting tab. However, in the command line, you can set it per group or user individually. You can push variables to the client program available to the client-side script as specified in the section above.