Linux VPN plugin failed error – What now?
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.
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.
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.
