Client Hook or Server Hook? Where an OpenVPN Script Runs

The task is clear: when a laptop connects, something on the laptop should change. The configuration being edited belongs to the server, and that is where the assumption breaks. A path in a server file names a file on that server, and no amount of pushing changes whose process executes it. Choosing between the two hooks is mostly a matter of deciding which machine owns the work and accepting the limits that follow.

Two machines, two questions to answer first

Ask where the state change has to happen, then ask which event corresponds to it. If the change is a per-user authorisation or a per-client configuration decision, it belongs where the user directory is known: the server. If the change is a route, a resolver setting or a local helper on an endpoint, it belongs on the endpoint, and only the endpoint can do it.

Answering those two questions in the other order is how people end up trying to push a batch file to a Windows laptop. The server knows who connected; the laptop knows what its own network stack looks like. Neither has the other's information, and the attempt usually fails quietly rather than with a clear error.

A third question is worth asking before either: does the platform even expose the hook you want? An appliance that generates its own configuration may not offer the same event names, and a desktop client that imports an .ovpn file is not necessarily the same client that the file was written for. Confirming the platform first saves you from designing around a hook that does not exist there. It also tells you which documentation actually applies to the machine in front of you.

The server-side option: a per-connection event

A client-connect script runs in the server's process context when an authenticated client connects, and it receives documented connection details such as the common name and the assigned address. It is the right place to write a per-client configuration fragment, enforce a policy decision or record state the server owns.

The distinction people miss is the difference between that hook and a server up hook. The up hook fires when the server opens its tunnel device, which happens once at daemon start on a multi-client server. It is not a per-login event, and code placed there runs when the service starts rather than when users connect.

On an appliance with a web interface, use the supported extension mechanism rather than editing generated daemon files. Generated files get rewritten on the next save, and the rewrite silently removes your change at the worst possible moment. Keep a copy of the extension text outside the appliance so a firmware update cannot lose the intent as well.

The client-side option: work that must run locally

A community client can run a local script when the tunnel device comes up and again when routes are installed. Those are two different moments, and picking the wrong one produces the classic race where a helper starts before the route it depends on exists.

The helper has to exist on that client, be readable and executable by the account running the client, and be permitted by an explicit script-security setting. A script that works when you launch the client as an administrator tells you nothing about a pre-login service or another user's session.

Naming matters too. The up hook corresponds to device creation and route-up to route installation, but a task that needs a private network to be reachable should verify reachability rather than assuming that device creation implies every route, resolver entry and application is ready.

Why pushing executable code is not on the menu

Pushed options are deliberately restricted, and options that execute scripts are among the categories the server is not allowed to hand down. That constraint exists because the alternative would let a compromised or misconfigured server run arbitrary commands on every client that ever connects.

Enabling script execution locally does not change that. Your script-security setting permits local scripts you chose; it does not authorise the server to supply new ones.

If the goal is simply to install VPN routes, use the supported route configuration instead of inventing a remote execution scheme. If the goal genuinely requires local code, distribute it through the organisation's endpoint management tooling and review it like any other software that runs with the user's privileges.

What to verify before you trust either hook

Write down four things for each hook: the machine, the event name, the account it runs as, and the state change it is supposed to produce. Then test the connection, a reconnection, and the cleanup path, because a hook that leaks state on reconnect is worse than one that never ran.

Test under the account that will actually execute it, at the moment it will actually execute. The openvpn(8) manual documents both hook families and the push restrictions; the platform you deploy on documents whether it exposes them at all. A script that succeeds in an interactive administrator terminal is a hypothesis, not a verification.