Windows OpenVPN Profile Fails on Ubuntu: Three Layers

Start the same profile from a terminal and the message most people copy is a warning, not the reason the client stopped. Three independent layers fail here: a pushed directive the Linux build does not implement, the rights needed to create a tun device, and the resolver helper that turns a connection into working DNS. Work down them in order, since each can hide the next.

Keep the download as it arrived and edit a copy, so a fresh download does not silently revert your changes.

Read the Warning Before Blaming It

block-outside-dns locks down DNS on Windows through the Windows Filtering Platform, and the Linux client has nothing to map it to. When the server pushes it, the client prints an unrecognized-option line for that pushed entry and carries on, because a pushed option is not treated as fatal. The identical line in your own file is a different matter: there the parser stops. Decide which of the two you have before touching anything, since only one of them ends the run.

To remove the noise, filter it before parsing: a pull-filter ignore entry for that name, or --ignore-unknown-option when the line lives in the local file. Both silence a line you have already read; neither repairs a failure you have not diagnosed.

Privilege Fails Before Anything Else Can

A tun device and the routes that accompany it are privileged objects, and a normal account cannot create them. The --user option explains the split: the daemon gives up its privileges only after the privileged work is done. Launch it as root, or through a unit that starts it that way, then look for a permission error before you look at certificates. Relaxing file permissions on the profile does not give the process the rights it lacks.

A TLS error means the client got past this layer. A device or route complaint means it never reached the layer above.

What the GUI Does That the Terminal Does Not

Connecting successfully while every lookup still fails is the third layer. NetworkManager does its own resolver work, which is why a desktop import can hand out DNS even when the profile's up script has never run successfully. A command-line openvpn --config executes whatever --up names, and if that helper is absent the interface appears while lookups keep going to the previous servers. Compare the two paths' scripts before installing anything.

Use the packaged helper for your distribution; a script copied from a blog post usually targets a different resolver. The integration shipped for systemd-resolved is not the generic vpnc-style script, and each expects its own arguments and variables from the client. User-defined up scripts also require script-security 2 before the client will execute them at all.

Separate the Layers on the Next Run

Run once with --verb 4 and read the log in the order it happened: device creation, routes, TLS handshake, then up-script output. The first failure in that sequence is the one worth fixing; everything after it tends to be a consequence. A tunnel that establishes while the resolver does not puts you on layer three, where the certificate is irrelevant. Leave the downloaded profile untouched while comparing.

Once each operator tweak produces another rejected line, the file is aimed at a different platform. Request a Linux export rather than building a permanent filter list.

Note which layer failed and what changed it, because the next person handed the same file will otherwise stop at the warning too.