Access Server Lost Its Binding After a NIC Rename: Fix the Keys

You renamed a network interface, or restored a machine whose adapter came back with a different name, and now the OpenVPN Access Server daemon will not come up. The web interface may still answer, or it may not, depending on which component was bound to the old name. The service is not corrupt, and the configuration is not gone; one setting still points at an interface the host no longer has.

The reflex is to reinstall, reinitialize, or edit the database until the error disappears. Each of those is a bigger change than the fault, and the last one can erase the users, permissions and profile dependencies that made the server worth recovering. This is a binding problem, and it has a named fix.

What the symptom actually tells you

A daemon that cannot bind usually says so in its own log: the address is not available, or the interface does not exist. That message is specific. It names the address the daemon tried, and comparing that address with ip -br addr on the host tells you whether the interface was renamed, removed, or merely brought up without the address it used to have.

Keep an authorized recovery console open the whole time. If the binding you are about to change carries your only administrative session, you have removed your own way back in. A local console, a second management address, or a documented out-of-band path turns a risky change into a reversible one.

Query the configuration before editing it

Access Server exposes its server configuration through its own CLI. The documented view is:

sacli ConfigQuery

Run it in the administrative environment documented for your installed release, not from an unrelated shell on a different host. Store the current values somewhere protected before you change anything, and do not paste the full output into a public support thread; it describes your deployment in more detail than a stranger needs.

That output is a server-configuration view, not a complete backup. User and group properties are queried separately, so a clean binding does not restore identities, and a restored identity does not fix a listener. If you need a full record, capture the configuration view and the user properties as two separate artifacts.

Identify which listener is broken

Access Server runs more than one listener. The OpenVPN daemons carry tunnel traffic, the web service carries the admin and client portal, and other components may carry their own ports. A failed browser request does not tell you which of them owns the failure, and neither does the port number in an error message.

The daemon binding keys are documented per daemon, and in the official binding tutorial the value is the interface identifier even though the key names end in ip_address. Read that sentence twice before typing an address into it. The tutorial's arrangement also expects the UDP and TCP OpenVPN daemons to share one interface, so correcting one daemon key and leaving the other is a partial repair that can look like a new failure.

Change the named setting, not matching rows

The daemon-binding tutorial documents ConfigPut against the specific keys, such as vpn.daemon.0.server.ip_address and vpn.daemon.0.listen.ip_address. Use the product's own method with the key name and the new value, in the syntax your installed release documents, and change only the keys that belong to the listener you diagnosed.

What you should not do is search the database for every row whose value equals the old interface name and replace them all. That approach assumes the old name appeared only in listener settings, which is not something the schema promises. It also makes the change impossible to review: a narrow setting change has a before and after, a bulk substitution has a diff nobody can read.

Two further temptations are worth refusing. Restoring a default that listens on every interface is an exposure decision, not a spelling correction; the intended local bind, the published path, and the filtering in front of it all have to agree with that choice. Reinitializing the configuration renames the problem instead of solving it, because a fresh install discards the very users and permissions that were working before the rename.

Apply it, then prove the path works

After the value is corrected, apply it through the product's documented lifecycle. The binding tutorial uses sacli start after setting the relevant keys, which is not the same as a full host reboot or a database reset.

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

Check the listener, then make one authorized VPN connection, reach one private resource, and load the administrative page through its expected path. Keep the existing user permissions and revocations; a recovery that resets them has fixed the binding and lost the deployment. The job is done when the same service works on its intended interface, not when a pristine default installation has replaced the configuration you were trying to save.