OpenVPN on Windows: autostart the tunnel and keep the routes

Two requirements get tangled here: the tunnel should come up before anyone logs in, and traffic for a second site should follow it. They are separate problems with separate mechanisms. Service startup decides the first, and route lifetime decides the second. Solving one leaves the other exactly where it was.

Step one: put the profile where the service looks

The Windows service reads profiles from a fixed directory, and the GUI reads from the same place, so a profile that works when you import it can still be invisible at boot. Place the .ovpn files in the config directory of the installation, which normally sits under Program Files. A profile left in a user's Downloads folder is not in scope for the service at all.

Older guidance points at a config-auto folder, which some 2.5-era builds honoured and later releases did not. That is why an upgrade can turn a working autostart into silence with nothing in the log about credentials. Confirm which directory the installed build actually reads before moving any files.

With several profiles on one machine, give each a named adapter through dev-node. Otherwise they compete for the same interface and the second fails in a way that looks like a credential problem.

Step two: start the service rather than the tray icon

Setting the OpenVPN service to Automatic makes it start at boot without a login. That is the mechanism, and the tray icon is not part of it. When the service owns the connection, the GUI may show no icon and no status, which is expected rather than a fault.

The consequence is that disconnecting means stopping the service, not clicking Disconnect. Tell whoever supports the machine, or the first support call will be about a missing icon.

Check that the service account can read the profile and the key material. A permission problem at boot looks exactly like an authentication failure in the log.

Step three: bind the route to the tunnel

A persistent entry is the wrong tool here. Adding a route with -P makes it survive reboots and, worse, makes it survive the tunnel closing. With the VPN down, the prefix still points at a gateway that is gone, so the host cannot reach that destination until somebody deletes the entry.

Three alternatives behave correctly. Push the route from the server, which adds it on connect and removes it on disconnect. Add it in a route-up script that reads route_vpn_gateway, so the next hop comes from the negotiated tunnel. Or use Add-VpnConnectionRoute with a native Windows VPN profile, which ties the prefix to that connection.

When the server offers more than this site needs, route-nopull refuses the pushed routes and leaves the table entirely local. That suits a shared profile whose users must not receive a corporate default route.

Step four: survive a cold boot

Starting the service before the network stack exists produces one failed attempt and no retry. Setting it to Automatic (Delayed Start), or adding a dependency on the network service, removes that race. Then repeat the boot test and check that a second attempt is no longer needed.

Route and adapter changes need administrator rights. A per-user startup shortcut does not have them, so a script that works from an elevated shell can silently do nothing at logon. Schedule it as a task with the highest privileges, or let the service own the change. Then test it as the user who will actually log in.

Test the sequence you actually deploy rather than the one you can trigger by hand. A cold boot is the only test that exercises the ordering.

Step five: verify without the GUI

After a reboot and a login, check three things without opening the GUI. The adapter should hold an address, the route table should show the site prefix with the tunnel gateway as next hop, and a ping to a far-side address should answer. Each check maps to a different mechanism from the steps above.

When the adapter never appears, the driver is the suspect rather than the profile. Those two failures look nothing alike in the log, and only one of them responds to reinstalling software.