OpenVPN Connect vs OpenVPN GUI: Where Windows Keeps Profiles

On Windows, "where is my OpenVPN profile" has two different answers, and picking the wrong one costs an afternoon. The community OpenVPN GUI treats a directory as its profile list: every .ovpn file in the configured folder appears in the tray menu, and a file removed from that folder disappears. OpenVPN Connect works from an import store, so it keeps a profile you deleted from disk and ignores a file you copied in. The comparison below is the one I use to decide which folder to open before touching anything.

A folder list versus an import store

The community GUI enumerates files at startup: it reads one configuration directory, chosen at install time, and a .ovpn file sitting there is a profile. Close the client, copy a file into that folder, start it again, and the entry is in the menu.

Connect instead builds its list from records it wrote during import, so a copied file is invisible while an imported profile survives deletion of the original download. That single difference explains most reports that the two clients store profiles somewhere different, because they do.

The community GUI: which folder is actually in use

Two folders matter. A per-user install reads %USERPROFILE%\OpenVPN\config; an all-users install reads C:\Program Files\OpenVPN\config, or the x86 path when the client is 32-bit. If a profile appears for one Windows account only, it is in the per-user folder and the other account will never see it.

Do not infer the path from the installer. The GUI accepts a --config_dir argument and remembers the directory it was started with, so a shortcut can point somewhere else entirely. Check the shortcut's target and Start in field, or the GUI settings, before you create any file.

Removal is file removal. Close the GUI first so it does not hold the entry in memory, delete the .ovpn together with any certificate or key files kept beside it, then start the client again.

The all-users folder needs an elevated delete. A delete that silently does nothing there is UAC, not a client bug.

Connect: the import store and the double-AppData trap

Current 2.x and 3.x builds keep profiles under %APPDATA%\OpenVPN Connect\profiles. Builds around 2.5 used %ProgramFiles(x86)%\OpenVPN Technologies\OpenVPN Client\etc\profile instead, which is why older forum answers and newer ones appear to contradict each other. A machine upgraded in place can still hold both.

The paths get mangled in retelling. %AppData% already resolves to AppData\Roaming, so writing %AppData%\Roaming\OpenVPN Connect\profiles expands to AppData\Roaming\Roaming and points at nothing. Use the variable or the literal path, never a mix of the two.

Delete through the client: open Profiles, use the pencil icon, choose Delete. That removes the record and the stored copy together. Removing the folder while Connect is running can leave a record that opens nothing, which is the "profile still shows up" complaint in its other form.

The imported copy is the one the client runs. Editing the .ovpn left in Downloads changes nothing, because Connect reads its stored copy; to change a remote or a cipher you edit the profile inside the client, or edit the file and import it again.

Why a deleted profile comes back

Two installs of the same client family is the usual reason. A per-user GUI and an all-users GUI have separate configuration directories, so deleting from one leaves the other intact and the tray still lists the name. Programs and Features is where you confirm whether both are installed.

The second reason is a profile that was never in the folder you checked. Opening an .ovpn once from a network share or a Downloads folder can copy it into the per-user config directory, and imported Connect profiles exist only in AppData. Before editing anything, search for the file name under both %USERPROFILE% and %APPDATA%. A profile folder usually holds the private key next to the .ovpn, so never paste the folder into a ticket or chat to prove which profile you removed - quote the file name and timestamp instead.

Older GUI builds also keep client preferences in the registry. If the tray still lists a name after the file is gone and only one install is present, restart the client once and re-check the shortcut's config directory before you consider touching registry keys.

Two tunnels at once: adapters first, then the route

The GUI can hold several connections, one per virtual adapter; add adapters from the Start menu entry that installs TAP-Windows6, then confirm the count in Network Connections, because two simultaneous tunnels need two adapters and both should obtain their address automatically. Routing is the harder limit. Two profiles that each redirect all traffic compete for the default route, and only one can own it, so you get intermittent failures instead of two working tunnels. Keep one full tunnel and give the second a split-tunnel profile that pushes only its own subnet.

Overlapping private ranges cannot be fixed by adding an adapter. If both servers hand out 10.8.0.0/24, the second tunnel collides at the address level and no amount of client configuration will separate them.

Adapter names tell you what you are looking at. Get-NetAdapter in PowerShell lists TAP-Windows adapters and the Wintun adapter by name, which is faster than counting icons in Network Connections when a tunnel came up on the wrong one.

Starting a named profile from a script

The GUI takes a profile name relative to its configuration directory, so a launcher looks like this: "C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --connect "myvpn.ovpn". An absolute path, or a process started in a different working directory, fails quietly, which is why a shortcut that works by double-click breaks under Task Scheduler.

Set the working directory instead of hoping. In an AutoHotkey launcher that is SetWorkingDir, C:\Program Files\OpenVPN\config; in Task Scheduler it is the Start in field of the action. Passing --config_dir with the same path makes the launcher independent of both.

Before you finish, export the profile, note its adapter, subnet and the subnet it routes, and keep each customer's certificates in its own subfolder. Then confirm the folder belongs to the client you actually run, and delete through the client when that client has an import store. Doing it in that order is what stops the same profile from reappearing after the next reboot.