Router OpenVPN Settings Revert After Reboot: Fix the Generator

Firmware on a consumer router or NAS often rebuilds its OpenVPN configuration at every start, so a directive you appended survives exactly until the next boot. The same applies to keys typed into a web form, where the stored value can come back mangled after a save. Neither symptom means the change was rejected. It means the edit landed in a file the firmware treats as output, and the durable place sits one step earlier in the boot sequence.

Why the edited file is regenerated

A start script assembles the server configuration from a template and then launches the daemon, which makes the rendered file a build artifact rather than a source. Anything appended after startup is invisible to the next run of that script. The second pattern is subtler: key and certificate inputs in the web interface are stored in an escaped form, and saving the form can push that escaped text into the file the daemon reads. Either way, the rendered configuration is the wrong place to make a lasting change.

Look at what the boot sequence writes and when it writes it. The answer is almost always a script under the firmware's init or autorun directory.

Insert the directive where the script builds the file

QTS appliances regenerate the OpenVPN server configuration inside the init script that starts the daemon, so the edit has to happen there. Add the append immediately before the startup command instead of editing the generated file.

sed -i '/daemon_mgr/i echo client-config-dir clientconfig >>/etc/openvpn/server.conf' /etc/init.d/vpn_openvpn.sh
grep -c client-config-dir /etc/openvpn/server.conf

Anchor the insertion on a command that will not move, since line numbers shift between builds. Because the init script is itself replaced during boot, the change must be reissued from the firmware autorun hook each time the system starts. After one reboot, count occurrences in the generated file: one line means the patch worked, while two mean the hook is running more than once. Investigate the double run separately, because it is not the same fault as a change that vanished.

Repair a form that stored escaped keys

On Asus-style pages the certificate and key inputs display escaped text, and a save after an unrelated tweak can write those entities back to disk. Work from a decoded copy and save only once, after all edits are ready.

openssl dhparam -out dh2048.pem 2048
grep -n "BEGIN DH PARAMETERS" dh2048.pem

When swapping in a new parameter set, paste just the base64 payload if the label asks for the key body, and keep the armor lines only when the field expects a full PEM block. Recovering a page already saved in its escaped form usually means clearing the affected inputs and applying, which lets the firmware build them again. Generate anything above 2048 bits on a workstation, because the router's entropy supply makes the operation slow and sometimes unreliable. Store the parameter file somewhere you can reach after a factory reset.

Recheck after upgrades

Firmware updates replace init scripts and can wipe the autorun directory, so the patch has to be reinstalled and tested again. Diff the regenerated file against the copy you kept and confirm the directive is present exactly once. A value visible in the web interface is not evidence that the daemon received it, since the page reads stored fields. Write the patch command and the firmware version into the maintenance notes so the next update carries them forward.

Then connect a client and read the server log for the pushed option. A setting that only ever existed in a form is a setting nobody has tested.