If you’re running Fedora 42 with KDE Plasma and you’ve been handed an OpenVPN .ovpn config file, odds are good you’ve already discovered a strange behaviour: the file works flawlessly when run directly in the terminal using:
| |
But then you try to import it into the GUI via KDE’s NetworkManager applet or nm-connection-editor… and it fails miserably. No helpful error, just “could not connect” or “invalid setting vpn: remote”.
The problem isn’t the file itself. It’s how KDE’s NetworkManager plugin parses and applies OpenVPN settings—often missing or mishandling crucial directives. This post walks through the exact issues I faced, how I solved them, and how you can get a reliable, GUI-compatible VPN configuration working on Fedora, without sacrificing control or stability.
Understanding the Errors
When I first tried connecting through the Plasma applet, the connection failed silently. Running journalctl -f -u NetworkManager gave me a better picture of what was happening under the hood. The logs showed three important messages: an error about block-outside-dns, a cipher negotiation failure, and a complaint about not being able to open a tun/tap interface.
The block-outside-dns warning is easy to dismiss—this option is pushed by some servers for Windows clients and isn’t supported on Linux. It’s safe to ignore. The tun/tap error was misleading in my case; /dev/net/tun existed and sudo modprobe tun confirmed the module was loaded. The real showstopper was the cipher negotiation failure. Newer versions of OpenVPN no longer accept all cipher suites by default. If the server uses an older or uncommon cipher (in my case, AES-256-CBC), the client must be explicitly configured to support it.
Breaking Apart the .ovpn File
The original .ovpn file used inline certificates for the CA, client cert, and private key, all embedded between <ca>, <cert>, and <key> tags. While this works fine with the OpenVPN CLI, KDE’s NetworkManager GUI doesn’t always handle inline certificates reliably. So I split them out into separate files.
I copied the certificate blocks from the config file and saved them as ca.crt, client.crt, and client.key respectively. I stored them in ~/.vpn/ and ran:
| |
on all three files to ensure they were secured and accessible only to my user. This allowed me to reference each file cleanly when building the new VPN profile.
Manually Configuring the VPN in NetworkManager
Since importing the .ovpn file through the GUI failed, I created the VPN connection manually using:
| |
I added a new OpenVPN connection and filled in the settings based on the contents of the original config file.
The remote gateway was set to <123.123.123.123> (protecting the innocent here), using TCP on port 1234. For authentication, I pointed NetworkManager to the CA cert, client cert, and private key I had saved earlier. I also set the cipher to AES-256-CBC, the auth method to SHA256, and enabled features like “Redirect Gateway”, “Float”, and “Persist Tun/Key” to match the behavior of the original file. Finally, I made sure the TLS minimum version was set to 1.2.
All of this matched what the CLI version of OpenVPN used—at least, on paper.
The Cipher Problem
Here’s where things got interesting. Even with AES-256-CBC selected in the GUI, the logs still showed a cipher negotiation failure. That’s because, starting with OpenVPN 2.5, the client only supports a few modern GCM ciphers by default unless explicitly told to accept others. The GUI setting wasn’t enough. It was only when I dug into the underlying .nmconnection file that I discovered the missing piece: the data-ciphers option.
Each manually-created VPN connection in NetworkManager is saved as a file under:
| |
I located mine and opened it with sudo. Under the [vpn] section, I added the following line:
| |
This line tells OpenVPN to advertise support for AES-256-CBC when negotiating with the server. Without it, even though the cipher was selected in the GUI, OpenVPN refused to use it. Once I added the line, I saved the file and set its permissions to 600:
| |
I reloaded the connection with:
| |
and then connected again using:
| |
This time, it worked instantly.
A Note on Failover
The original .ovpn file had multiple remote entries for fallback servers. KDE’s NetworkManager doesn’t support multiple remotes in a single profile, so the workaround is to duplicate the profile, change the remote value in the second .nmconnection file, and treat it as a manual backup. It’s not elegant, but it gets the job done if your primary VPN endpoint becomes unreachable.
Thoughts
I love the Fedora and KDE Plasma stack. But needing to use OpenVPN for my specific use case gave me a few headaches. The GUI tools are convenient, but they don’t always surface the full range of OpenVPN’s configuration options. If you rely on GUI-based workflows, it’s important to understand where these limitations exist and how to bypass them when needed.
In this case, taking control of the .nmconnection file and adding data-ciphers=AES-256-CBC was the key to resolving the connection failure. The rest, like file permissions, TLS settings, persist options all fell into place with a bit of manual tweaking.
If you’re running into a similar issue and don’t mind getting your hands dirty, editing the config directly gives you full control and a much smoother connection experience.