OpenVPN fails with no log output when config file is empty or (sometimes) has a non-whitespace syntax error

[badon]

If a functional OpenVPN config file has an error in the first parsed item on a line, and the error is not extra whitespace, then OpenVPN will fail without any log output, which normally should indicate the first occurring syntax error on a specific line. The same result (maybe a different bug) will also occur if the config file has only a single empty line.

I have config files where this bug does NOT occur, but I'm not sure how they are getting around the code that triggers this bug. That may be a different bug, if somehow the syntax error is not being logged or not being detected. Those config files are a lot more complicated, but I think the simplest case with a config file that either has no content, or has only a single line with a single character is sufficient to reproduce this bug and fix it. It might be possible to isolate the bug where my other config files failed to log a syntax error, after this bug is fixed. Obviously, accurate log output will be helpful.

I chose to give this report "blocker" priority, because it conceivably can prevent research of other bugs, due to lack of log information. For example, it took me more than a year to notice a single character error in the config file that triggers this bug, which prevented isolation and reporting of such a simple bug. The fact that other, more complex config files had the same error, but did NOT trigger the bug, made it more difficult to find the problem. If the problem weren't an obvious syntax error, I would never have found it, and I never would have been able to report this bug (and thus fixing it would have been "blocked").

Tested with: OpenVPN 2.3.7 i686 (x64) Windows 7.

My search for previous reports of this bug:

​https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=new&status=reopened&summary=~log&col=id&col=summary&order=priority

Despite how simple this bug is, I was surprised there were no previous reports of it. I think the fact that it results in no log output is the sole reason why no one was able to report it.

[Gert Döring]

Plaisthos: another magic 3-line fix?

[plaisthos]

When you say "no log output" do you no logging to a file or no message to the console? How are you starting OpenVPN under windows?

The issue query does not yield any bug which seem to be related in any way to this bug.

A single empty line gives me:

Options error: You must define TUN/TAP device (--dev)
Use --help for more information.

as expected.

If I cannot reproduce a bug in a simple way, it is not a "simple bug"

[badon]

OK, then something more must be required to trigger this bug. This is completely reproducible on my system. I am starting OpenVPN GUI as administrator with a Windows shortcut that has the "target" as:

"C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --connect "some file.ovpn"

There is no logging to file, AND no message to the console. I don't have any problems with TUN/TAP in Windows, but maybe that's something that needs to be tested further to help you reproduce this bug? Do you run it as administrator?

[plaisthos]

Instead of starting OpenVPN from a shortcut you should run the command from cmd.exe and see if that makes a diffences.

Probably OpenVPN logs the error and then the cmd window immediately closes without you having the chance to see the message.

[Gert Döring]

@badon: have you tried running "openvpn.exe somefile.ovpn" directly from the CLI to see whether the problem is just in communicating the error back to the GUI (which is likely for a parsing problem)? This is sort of a known issue and not easy to fix, but it would be good to understand whether you're hit by that...

[januzi]

Hello

I've spent some time trying to find a reason why I couldn't connect to the server. Let me tell you this, empty log file wasn't helping at all. Yes, there was parsing problem, and the Windows app should point it directly to the user. At this point it is just saying "I'm using this config file you've provided, everything is fine, carry on" and then it just fails trying to connect ... localhost, I guess, or something else that is set as default host (if empty, then why ffs it takes 2 minutes to display an error message?). I've tested the newest version and the problem is still there. You have got two options:

1. modal window saying that there is an error in the config file (+ the problematic line/s)
2. an error message in the client.log, or better, in the error.log

First one is better. That way you will point the user right into the proper direction. I hope that you'll fix this problem soon. And I mean FIX IT. Do not put another line into the FAQ saying what users should do. That's lazy way.

[Gert Döring]

Hi,

Replying to januzi:

First one is better. That way you will point the user right into the proper direction. I hope that you'll fix this problem soon. And I mean FIX IT. Do not put another line into the FAQ saying what users should do. That's lazy way.

I agree that this would be a good thing to have. We welcome your patches to openvpn-gui.

[Selva Nair]

This is caused by two issues:

(i) The GUI does not pass "--log" as the first option, so such early errors do not get written to the log
(ii) The GUI communicates with OpenVPN through the management interface, but such errors happen before the management interface is connected.

(i) is fixed in the following pull request

​https://github.com/OpenVPN/openvpn-gui/pull/15

For (ii) a partial remedy is in the following pull request

​https://github.com/OpenVPN/openvpn-gui/pull/16

If an "early exit" by openvpn is suspected, it pops up a message box asking the user to view the log file for details.

Note that log is best viewed the "View Log" menu entry, to be sure that one is looking at the right log file. Note, however, "View Log" was buggy before commit 09334e71a0277ecf00e45b389c9238a150e13317

[Samuli Seppänen]

Replying to selvanair:

I merged the two pull requests today. The fixes will be (soon) included in:

• OpenVPN 2.4-alpha* installers
• ​Git snapshots builds (some plumbing is needed first)

[Samuli Seppänen]

This has now been fixed in latest Git "master" ​snapshot installers.

[Samuli Seppänen]

Selva's fixes probably won't be backported to OpenVPN 2.3 - too much effort for too little gain. Plus we want to keep OpenVPN-GUI in OpenVPN 2.3 installers as stable as possible.h

[Samuli Seppänen]

We discussed this bug in today's IRC meeting and agreed that the Selva's fixes are good enough. I'm closing this bug now.