OpenVPN Access Server: Restart the Daemon or Apply the Setting

Two commands get pasted for what looks like the same job on OpenVPN Access Server, and they do different things. systemctl restart openvpnas stops and starts the whole product. sacli start brings up the internal services that read the configuration you just changed. Choosing between them is not a matter of taste: it depends on what the setting's own documentation says, whether your session runs through the server you are about to restart, and whether you are even looking at the right product.

Two layers, one daemon

Access Server runs as a single systemd unit, openvpnas, and that daemon supervises the internal services behind the web interface and the VPN listeners. sacli is the command-line interface into the same installation, at /usr/local/openvpn_as/scripts/sacli, and it can start, stop and query those internal components without replacing the unit.

That is why both commands exist. A daemon restart re-executes everything, including the process that terminates client tunnels. sacli start asks the already-running daemon to bring its components up so they read the new configuration, which is what most property changes actually require.

Condition one: what the setting documentation says

Read the page for the setting you changed, not for a setting you changed last month. A property written through ConfigPut is normally followed by sacli start, and that pair is the documented apply step. A change to listener-level behaviour, or anything the page describes as requiring a service restart, is the class where the unit restart is correct.

The two commands are not interchangeable, so the failure mode of guessing is asymmetric. Using sacli start when a full restart was required leaves you with an old process still serving the previous configuration, which looks like the setting was ignored. Using a full restart when sacli start would do drops every connected client for no reason.

Condition two: is your own session inside the tunnel

If you administer Access Server over the VPN it provides, the restart removes the connection carrying your shell. The command may complete after your session dies, which leaves you guessing whether it worked. sacli start can interrupt a session briefly for the same reason when the component being restarted handles your traffic.

Have an out-of-band path open before either command: a provider console, a hypervisor console, or a serial session. This condition decides when you run the command, not which command you run, and it is the one that turns a two-minute change into an outage report.

Condition three: is this the product you think it is

Access Server is not Community OpenVPN. A community installation runs units such as openvpn@server or openvpn-client@profile, with configuration in /etc/openvpn, and sacli does not exist there. Restarting every unit with openvpn in the name on a shared host is how unrelated tunnels go down together.

Identify before touching anything: systemctl status openvpnas --no-pager answers whether Access Server is the thing running, sacli status lists its internal components, and systemctl list-units --type=service lists units whose names contain openvpn. If the last command shows profile-named units, you are on the community product and the rest of this does not apply.

Apply it, then verify past active

A unit that reports active has a running process, which is not the same as a working authentication path. After the apply step, check sacli status for the components you expected to restart, confirm the value was stored with sacli ConfigQuery, and then run one limited client login against a test account.

Finish with something application-level: reach a private resource through the tunnel, not just a ping to the server's public address. A handshake that succeeds while the pushed route or the DNS setting is wrong will pass every service check and still fail the person who reported the problem.

The vendor's service-management tutorial is the reference for which operations belong to sacli, and it is worth opening before you decide that a restart is the safe option.

The decision in one pass

Work down these four lines and stop at the first one that matches:

• The setting page names sacli start, or you just ran ConfigPut: use sacli start.
• The page requires a restart, or the change touches listeners rather than properties: use systemctl restart openvpnas.
• Your shell arrives through this server: arrange console access first, then run whichever command the two lines above chose.
• Verification: sacli status, ConfigQuery for the value, one login, one private resource. Service state alone is not the finish line.

Two of those lines are checks and two are actions, which is the point of the order. If you cannot answer the product question, stop: the command you were about to run belongs to a different installation, and the tunnel you take down will not be the one you meant.