Linux VPN plugin failed error - What now?

Updated: May 24, 2019

This is an obscure problem. An alarming one. But there's a happy ending. So let me introduce the problem statement. On me Slimbook, which happily runs Kubuntu Beaver, I set up a VPN connection, to see how well the operating system handles all manner of things, technologies and use cases. This wasn't trivial, as a necessary package was missing and whatnot, but in the end, I got things running.

Then, suddenly, things stopped running. The VPN would no longer connect, with a rather ambiguous error showing in the system log (nothing else is shown to the user, there's just a silent fail on connect) reading something like: VPN plugin: failed: connect-failed (1). My first thought was, oh noes, a regression. But rather than just blaming Kubuntu, I decided to dig into this some more.

Teaser

Note: Image courtesy of Freeimages.com/fabrizio turco.

Problem in more detail

If you've followed my Slimbook combat reports, then you know that there are problems, including an occasional regression or bug sneaking in under the radar. That means I cannot be 100% sure that the operating system always provides a rock-solid, immutable, dependable base. There's always some doubt.

Naturally, when a testing session goes wrong, and a couple of other things seize up, the first thought you have is that someone borked yet another component. Anyway, there was no visible error message of any kind. In the logs, I had the following:

Jan 30 10:12:38 slimbook NetworkManager[1886]: <warn> [1548843158.8280] vpn-connection[0x55a61eff3800,9eed06ec-8e33-4c59-ac18-fdbbc3ca4591,"Il mio VPN",0]: VPN plugin: failed: connect-failed (1)

Then Internet magic box of answers says this is OpenVPN related, whereby since version 2.4, the layout of folders and configurations on the disk has changed. This indeed breaks the flow, and I find it puzzling that something like this can happen, but hey, open-source, Linux, let's ignore stability. However, this particular bug was resolved before I'd purchased the Slimbook, and I did have the right directory tree under /etc, so this wasn't that. Something else, then.

Solution

At this point, what I did was examine every piece of the stack, one by one. Looking at the VPN configuration in the network manager, I examined every listed option and file, and found out that there was an issue right there, caused entirely by PEBKAC! Myself! Somehow, for some odd reason, I had moved the actual key to a different folder, and the VPN was not able to find it. Restoring the key back to the expected location fixed the issue right away.

VPN, key missing

Now, the ideal solution would be for the network manager to cache keys, or warn the user that the key file is missing. I mean, this is the obvious thing, so if there are misconfigurations, they should be explained in a way that helps users troubleshoot the issue in a clear manner. Saying 'plugin failed' doesn't mean anything.

But you may say, why are you ever bothering writing this article, you caused the issue! Correct. But, the problem manifestation wasn't obvious, the error wasn't obvious, the blame factor wasn't obvious, and even shifting blame from Kubuntu to OpenVPN, which seems trivial given the bug report above, doesn't help advance the resolution in any way. Lastly, the operating system does not handle this exception gracefully. Far from it, the error message is misleading.

Hence, this tutorial.

Conclusion

I could have just fixed this and moved on, and no one would know or care. Alternatively, I could have just given up and laid blame on this or that factor, which is quite often what people do. It's much harder to introspect and self-examine usage patterns. But it's a necessary part of the problem solving method. I am happy to exonerate the operating system and the VPN software.

However, I also thing there's a lot of room for improvement. Generic error messages lead to generic solutions that don't really help. I could have stopped at that VPN bug report. I believe the software should be more robust and intuitive, and that errors have to reflect the exact cause rather than a seemingly random entry in the error table. Well, hopefully, some of you will find this article interesting. It's not about any particular mishap, it's about how to handle unknown issues and not get blinded by false positives. We're done.

Cheers.