OpenVPN Starts at Login but Not at Boot on Windows?

Tunnels that appear only after someone signs in are usually launched by that person's session, not by the automatic service. The usual culprit is a startup shortcut that launches openvpn-gui.exe, and it is not a broken installation. The shortcut starts a desktop application inside a user session, with that user's profile, that user's certificate stores and that user's ability to answer a prompt. Nothing about it makes the connection independent of a signed-in human, which is precisely what a pre-login tunnel requires.

The Symptom Usually Has Three Causes

Three patterns look alike from the outside and have different fixes. The first is an execution owner that is a user session rather than the service, which is the startup-shortcut case. The second is a profile that lives where the service does not look, so the service starts, finds nothing and exits cleanly. The third is a profile the service finds and starts, but whose credentials need an interaction no service can supply.

Identifying which one applies takes two reads: what the service is configured to run, and which files it can see. Both are one command each, and neither disturbs a running connection.

What the Automatic Service Actually Reads

The Community automatic service is a wrapper that scans its configured auto-start directory, normally config-auto under the installation, and launches an OpenVPN process for each matching profile it finds. A profile visible in a user's GUI menu lives under that user's roaming profile instead, in a directory the service account does not read. The Windows service guide describes that discovery, and it is worth reading before copying anything, because the target directory is a property of the installation rather than a fixed convention. Copying a file into the GUI's folder therefore changes nothing for the service, and copying it into every folder called config creates duplicates rather than a fix.

Get-Service OpenVPNService | Select-Object Status, StartType
Get-CimInstance Win32_Service | Where-Object Name -eq 'OpenVPNService' | Select-Object PathName, StartName
gci 'C:\Program Files\OpenVPN\config-auto'

The last command lists what the wrapper will actually see, which is the fastest way to confirm that a profile is in the wrong place. The second line also shows the account the service runs as, and that account decides which file paths and certificate stores are reachable at all.

Why a Desktop Login Works and a Boot Start Does Not

Desktop success can hide an input dependency for a long time. A GUI can collect a key passphrase, an account password or a second factor in a dialog, because it runs in an interactive session with a visible desktop. A service runs in a session with no desktop, so a request for input has nowhere to appear, and the connection fails after a timeout that looks nothing like a credential problem.

File access follows the same rule. A private key stored under the user's profile, or a certificate in the user's personal store, is not available to a service running as the machine. Compare absolute paths, permissions and the certificate selection each side makes rather than assuming the same profile file implies the same environment.

A scheduled task set to run whether a user is logged on or not inherits a similar constraint. It may start the GUI executable successfully and still produce a process that never obtains credentials, so the presence of a process in the task manager is not evidence of a working tunnel.

Pick One Owner and Test the Real Lifecycle

For a connection that belongs to a signed-in person, use the GUI's supported autostart behaviour and leave the service out of it. For a tunnel that must exist before anyone signs in, configure the service, place the profile where the wrapper reads it, and use a supported unattended credential mechanism such as a key without an interactive passphrase or a documented credentials file.

Get-Content 'C:\Program Files\OpenVPN\log\openvpn.log' -Tail 40
Get-WinEvent -LogName Application -MaxEvents 20 | Where-Object ProviderName -like '*OpenVPN*'

Test the lifecycle that matters: a reboot with nobody signing in, then a reconnect after a network change. Keep one owner for the connection, because two competing startup mechanisms usually produce two instances fighting over the same routes and the same server session, which is harder to diagnose than either mechanism alone.