Tunnelblick could not find a 'tun' or 'tap' option in the OpenVPN configuration file

[Octapon]

I've been using tunnelblick for years. Today I got the "new version" notification and I upgraded my tunnelblick, as I've done immediately whenever newer versions are released.  once upgraded, however, I'm no longer able to connect to my vpn.  I get the following message:

Tunnelblick could not find a 'tun' or 'tap' option in the OpenVPN configuration file

there are no log statements associated with this failure.  nothing has changed with my previously working config file, so it seems unlikely that's the problem.  I was on stable builds only, but tried upgrading to the latest beta 4544, but am seeing the same behavior.  

Has anyone else experienced breakage of their VPN by the upgrade?

[jkbull...gmail.com]

I'm sorry about this problem; it probably has to do with Tunnelblick now checking the configuration file to make sure it is safe to use. Nobody else has reported this that I recall.

To help find and fix the problem:

1. Please click the Tunnelblick icon, then select "VPN Details...".
   
2. In the window that appears, click on the large "Configurations" button on the top.
   
3. In the list on the left side of the window, click to select the configuration that is experiencing this problem.
   
4. Click the "Copy Diagnostic Info to Clipboard" button.
   
5. Open a reply to this email, either in your email program or on the Tunnelblick Discussion Group website.
   
6. Edit > Paste into the reply.
   
7. Look through what was pasted and remove any sensitive information such as IP addresses (replace them with "XXX" or similar), email addresses, and whatever comes after the "remote" option in the listing of the configuration file. (Highly sensitive info such as inline keys has already been removed.)
   
8. Send the reply.
   

[stre...@gmail.com]

Had this problem too this morning after upgrading to the latest version.

The reason was a missing line break at the end of the configuration file. I tend to use config files with keys included so one of my config files ends by "</tls-auth>\n" what seems to cause the error. I added an additional line break "\n" and now it works like before.

I had to import the config file again. Seems easier than running through all the chmod-procedures.

[jkbull...gmail.com]

@streich7 -- Thank you very much for your comment. I will look into fixing that bug.

To make sure I understand you correctly, when your file ended in

</tls-auth>\n

Tunnelblick didn't "see" the tun option (or tap option), but when you changed it to

</tls-auth>\n\n

(in other words, with an empty, blank line after the </tls-auth> line) it worked OK?

(Or was it that it ended at </tls-auth> -- without a \n at the end of the file, and having a single \n at the end of the file made it work?)

[jkbull...gmail.com]

@streich7 - I can't reproduce what you describe: no \n, one \n, or two \n at the end of the file all work OK for me.

I suspect something else might have changed between the installed version (which produced the error message) and the file you used to "import the config file again".

Could you test the file you imported (which worked) but changed to remove all \n at the end of the file?

Thanks.

[stre...@gmail.com]

@jk - OK let's disassemble this a bit more.

My config file ended like this:

85ac77c5754b8018eb1aabd62498f251

-----END OpenVPN Static key V1-----

</tls-auth>

Tunnelblick logs an error:

Tunnelblick: Error returned from 'openvpnstart printSanitizedConfigurationFile vps03 0':
Tunnelblick: Error parsing configuration at line 248; unterminated <tls-auth> at line 228
There was a problem in the configuration file at /Users/USERNAME/Library/Application Support/Tunnelblick/Configurations/SERVER.tblk/Contents/Resources/config.ovpn

When I add a blank line at the end of the config file it is working again. Meaningless if I add the blank line at my config file and reimport or edit the tblk-file directly.

So it seems when there's no blank line at the end of the file Tunnelblick looses the last line of the config file.

To be as clear as possible: set your cursor behind "</tls-auth>" and press Enter TWICE so it looks now like this:

85ac77c5754b8018eb1aabd62498f251
-----END OpenVPN Static key V1-----
</tls-auth>

I can reproduce this with two of my config files a few minutes ago. I guess it's a parser-thing...

[jkbull...gmail.com]

@streich7 - Thanks. I appreciate your help trying to find and fix this bug.

Are you using Tunnelblick 3.6.0a or 3.6.1beta02?

If not, please update to either one and see if you still have the problem.

If you are using either of those versions, could you please send me (privately to my Gmail address of jkbullard) a .zip of your config file after removing some of the private key info (between the --BEGIN and --END)? (And making sure the redacted version still fails to install, of course.) With that, I could debug the problem.

Thanks.

[stre...@gmail.com]

@jk - some more details.

This is the config file:

iMac:~ USER$ tail -n 3 ~/Documents/xxx/vps03.ovpn

85ac77c5754b8018eb1aabd62498f251
-----END OpenVPN Static key V1-----
</tls-auth>

iMac:~ USER$

When imported it looks like this:

iMac:~ USER$ sudo tail -n 3 /Library/Application\ Support/Tunnelblick/Shared/vps03.tblk/Contents/Resources/config.ovpn

85ac77c5754b8018eb1aabd62498f251
-----END OpenVPN Static key V1-----

</tls-authiMac:~ USER$

Note the beginning of the last line. Does not work in Tunnelblick.

So I nanoed two additional carriage returns.

iMac:~ USER$ tail -n 5 ~/Documents/xxx/vps03.ovpn

85ac77c5754b8018eb1aabd62498f251
-----END OpenVPN Static key V1-----
</tls-auth>

iMac:~ USER$

Import again and it looks and works like this:

iMac:~ USER$ sudo tail -n 3 /Library/Application\ Support/Tunnelblick/Shared/vps03.tblk/Contents/Resources/config.ovpn

85ac77c5754b8018eb1aabd62498f251
-----END OpenVPN Static key V1-----
</tls-auth>

iMac:~ USER$

Looks like while importing some characters get lost.

Am Montag, 21. März 2016 13:46:10 UTC+1 schrieb jkbull...gmail.com:

[jkbull...gmail.com]

@streich7 - Ah. It is the installed copy, not the original, that has no \n at the end. I'll try to reproduce that. Thanks.

[stre...@gmail.com]

@jk - Come back if you still need the config file, you're welcome.

[jkbull...gmail.com]

@streich7 - Thanks. I still can't reproduce it, even with a copy in /Library/Application Support/Tunnelblick/Shared not having a \n at the end of the file(

So if you can create and send me a redacted config that shows the problem, I would be very grateful. I'll copy it directly into .../Shared, instead of installing it. (Please send it to by Gmail address, jkbullard.)

I hate problems like this -- and it should be easy to fix (if I can find out what it is!)

[jkbull...gmail.com]

streich7 sent me a configuration file and some comments, and I now understand the problem (partly, anyway).

Thanks again, streich7, for all your help with this.

As a workaround for the problem, try putting a few empty lines at the end of the configuration file. (Five or six should be enough.)

The problem may primarily affect shared configurations, so you might try it as a private configuration if the extra lines don't help.

I will post to this thread when I have fixed the problem.

On Monday, March 21, 2016 at 6:54:49 AM UTC-4, <> wrote:

[jkbull...gmail.com]

On Mon, Mar 21, 2016 at 12:52 PM, Octapon wrote TO ME PRIVATELY:

hi jk.  thanks for the attention.  I tried adding the newlines to the end of the config file, but go no love.  I was already operating in private, unshared mode.  I was a little sketched sending my config to the mailing list, so I'm sending it only directly to you.  any more ideas or things I can try?

I understand that reluctance, no problem.

And I'm sorry this is a problem for you -- you apparently have a completely different problem than streich7.

Your configuration file looks OK, and it has the necessary "dev tun" line, so the only other thing I can think of is that there are invisible characters in it somewhere. Sometimes that is the result of having a file from Windows. Windows uses the invisible characters CR (0x0D) and LF (0x0A) to terminate lines, but OS X uses only a LF. So the CR looks like a garbage character to some OS X programs (including Tunnelblick and OpenVPN).

(When you install a configuration, recent versions of Tunnelblick filter out or complain about such characters, but that doesn't happen when you connect an existing configuration, only when you install or replace a configuration.) So you could just re-install.

Or you might want to try using a line-ending-santitizer program such as "ConvertNewlines". I downloaded it years ago from 

https://lionel.kr.hs-niederrhein.de//~dalitz/data/software/macosx/. Look for the "Some useful little tools" section at the bottom of the page. You need to find the file in a Finder window, and then you drag/drop it onto the ConvertNewLines application and then click "Unix" to get Unix (and OS X) line endings.

Private configurations are stored in

/Users/YOUR_USERNAME/Library/ApplicationSupport/Tunnelblick/CONFIGURATION.tblk/Contents/Resources/config.ovpn

[jkbull...gmail.com]

Investigating this further, it looks like the problem that streich7 is having is caused by odd character sequences in comments in the configuration file. For each such two-character sequence (0xC2 0xA0, which is a sequence for a Unicode space character) in the file, Tunnelblick cuts off one character at the end of the file! I think it is because the two-character sequence maps to a single space character.

I'll report back here when I have more.

[jkbull...gmail.com]

The problem Octapon was having was appears to be because his configuration file included CR (0x0D) characters. It was resolved by re-installing the configuration because installing a configuration with a new version of Tunnelblick automatically removes those characters.

The problem streich7 was having is a different bug in Tunnelblick. I have fixed it in GitHub commit 2096729 and the fix will be in the next release.

So if you are having this problem (Tunnelblick could not find a 'tun' or 'tap' option in the OpenVPN configuration file), you should

1. Add a bunch of empty lines at the end of the configuration (maybe 20 or so), then
   
2. Reinstall the configuration.

That should take care of both problems.

[ma...@manngo.net]

I found another problem leading to this error. For some reason, I had the following at the end of my file:

#key-direction 1
#<tls-auth>
#-----BEGIN OpenVPN Static key V1-----
#. . .
#</key>

Obviously left over from something or other. The point is that these lines were commented out, but were read anyway. Deleting them solved my problem.

[jkbull...gmail.com]

Thank you very much for reporting this. Your report resulted in fixing one bug and discovering another one (which is only tangentially related and is not fixed yet).

The problem was actually the line

#-----BEGIN OpenVPN Static key V1-----

because there was no corresponding "-----END" of the key information.

To ensure that Tunnelblick doesn't process key or certificate info -- even in comments -- Tunnelblick skipped everything after that line, looking for a line with "-----END" but since there wasn't one, it considered that to be a parsing error. I have must committed a change to the source code that now ignores that error, allowing successful connections with configurations such as yours with the commented-out lines.

However, this situation means that certain valid OpenVPN configurations will not be parsed properly. For example, a single line comment

#-----BEGIN OpenVPN Static key V1-----

at the beginning of the file will cause the entire file to be ignored when Tunnelblick parses it for OpenVPN options, because it contains the "magic" string "-----BEGIN", but there is no corresponding "-----END".

I consider that to be acceptable because it is easy to avoid such configurations. Most of the time a commented-out key or certificate will include both "#-----BEGIN" and "#-----END", so the situation shouldn't occur often.

In debugging this, I noticed/realized that when Tunnelblick is updated (via it's normal, Sparkle-based updater), apparently OS X caches the "tunnelblickd" daemon program in a way that means that a new version of the daemon included in the update is not used until the user next restarts OS X. I will be working on that.