Tunnelblick Kext Verification Error

edwar...@gmail.com

unread,

Mar 18, 2016, 9:53:38 PM3/18/16

to tunnelblick-discuss

In the new 3.6.0 version of Tunnelblick, I can't connect to a VPN server.

It spits out the error that there was a verification error while loading one of the kexts, notably: /Applications/Tunnelblick.app/Contents/Resources/tap-signed.kext/

Before anyone asks, this kext does exist where Tunnelblick says it exists. It appears that Tunnelblick may be checking the kext against a checksum given to it, which is invalid.

I'm running on the beta channel now, and it does work.

jkbull...gmail.com

unread,

Mar 18, 2016, 9:58:43 PM3/18/16

to tunnelblick-discuss, edwar...@gmail.com

There should be no difference in the kexts in 3.6.0 and those in 3.6.1beta02.

Is it possible that you restarted your computer between trying 3.6.0 and 3.6.1beta02?

What exactly is the error message that you are seeing?

What version of OS X are you using?

edwar...@gmail.com

unread,

Mar 18, 2016, 10:18:51 PM3/18/16

to tunnelblick-discuss, edwar...@gmail.com

I didn't restart my computer between trying 3.6.0 and 3.6.1beta02.

I just reinstalled 3.6.0 and tested it again, and it's still giving me the same error:

Could not start OpenVPN (openvpnstart returned with status #226)

Contents of the openvpnstart log: 

*Tunnelblick: openvpnstart log: 

     Loading tap-signed.kext 

     stderr from kextload: /Applications/Tunnelblick.app/Contents/Resources/tap-signed.kext failed to load - (libkern/kext) validation failure (plist/executable); check the system/kernel logs for errors or try kextutil(8). 

     stderr from kextload: /Applications/Tunnelblick.app/Contents/Resources/tap-signed.kext failed to load - (libkern/kext) validation failure (plist/executable); check the system/kernel logs for errors or try kextutil(8). 

     stderr from kextload: /Applications/Tunnelblick.app/Contents/Resources/tap-signed.kext failed to load - (libkern/kext) validation failure (plist/executable); check the system/kernel logs for errors or try kextutil(8). 

     stderr from kextload: /Applications/Tunnelblick.app/Contents/Resources/tap-signed.kext failed to load - (libkern/kext) validation failure (plist/executable); check the system/kernel logs for errors or try kextutil(8). 

     stderr from kextload: /Applications/Tunnelblick.app/Contents/Resources/tap-signed.kext failed to load - (libkern/kext) validation failure (plist/executable); check the system/kernel logs for errors or try kextutil(8). 

     Unable to load net.tunnelblick.tun and/or net.tunnelblick.tap kexts in 5 tries. Status = 71

I'm using OS X El Capitan 10.11.1.

Is it possible that Tunnelblick compares the kext against a checksum, and the checksum that Tunnelblick compares it against is wrong (in the stable release)?

jkbull...gmail.com

unread,

Mar 18, 2016, 10:42:35 PM3/18/16

to tunnelblick-discuss, edwar...@gmail.com

Thank you very much for reporting this.

The tap kext (and the tun kext, although that is rarely used) from Tunnelblick 3.6.0 cannot be loaded, but those from 3.6.1beta02 can.

I understand why it is happening and it will fix it as soon as I can. (It has nothing to do with checksums or corruption or anything like that; it has to do with more strict enforcement of formatting requirements in kexts by El Capitan. Apparently the fix for this problem, which was created months ago, has been lost or not included in the release.)

Until it is fixed, please use the beta.

Anyone else with this problem can update to the beta very easily: on the "Preferences" panel of the "VPN Details" window, put a check in "Check for updates to beta versions", then click the "Check Now" button and you will be be offered an update to the beta.

Bob

unread,

Apr 14, 2016, 12:28:20 PM4/14/16

to tunnelblick-discuss, edwar...@gmail.com

I think I am seeing the same issue I on 3.6.2beta06

*Tunnelblick: OS X 10.10.5; Tunnelblick 3.6.2beta06 (build 4555); prior version 3.6.1 (build 4543.4551); Admin user

git commit 88a1868a4d304de922ab3e57e8dddea7ac131b02

================================================================================

Non-Apple kexts that are loaded:

Index Refs Address Size Wired Name (Version) <Linked Against>

125 0 0xffffff7f80a1d000 0x7000 0x7000 net.sf.tuntaposx.tun (1.0) <7 5 4 1>

126 0 0xffffff7f80a27000 0x7000 0x7000 net.sf.tuntaposx.tap (1.0) <7 5 4 1>

134 3 0xffffff7f82b83000 0x57000 0x57000 org.virtualbox.kext.VBoxDrv (4.3.20) <7 5 4 3 1>

136 0 0xffffff7f82bda000 0x8000 0x8000 org.virtualbox.kext.VBoxUSB (4.3.20) <134 81 39 7 5 4 3 1>

137 0 0xffffff7f82be2000 0x5000 0x5000 org.virtualbox.kext.VBoxNetFlt (4.3.20) <134 7 5 4 3 1>

138 0 0xffffff7f82be7000 0x6000 0x6000 org.virtualbox.kext.VBoxNetAdp (4.3.20) <134 5 4 1>

139 0 0xffffff7f82bed000 0x3000 0x3000 com.avast.PacketForwarder (2.1) <4 1>

140 0 0xffffff7f82bf0000 0x8000 0x8000 com.avast.AvastFileShield (3.0.0) <5 4 1>

================================================================================

There are no unusual files in client.tblk

================================================================================

Configuration preferences:

-routeAllTrafficThroughVpn = 1

-lastConnectionSucceeded = 0

================================================================================

Wildcard preferences:

================================================================================

Program preferences:

launchAtNextLogin = 1

notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0

askedUserIfOKToCheckThatIPAddressDidNotChangeAfterConnection = 1

tunnelblickVersionHistory = (

"3.6.2beta06 (build 4555)",

"3.6.1 (build 4543.4551)",

"3.6.0a (build 4543.4546)"

)

lastLaunchTime = 482343338.500834

connectionWindowDisplayCriteria = showWhenConnecting

maxLogDisplaySize = 102400

lastConnectedDisplayName = client

keyboardShortcutIndex = 1

updateCheckAutomatically = 1

updateCheckBetas = 1

updateSendProfileInfo = 1

NSWindow Frame ConnectingWindow = 525 530 389 187 0 0 1440 877

detailsWindowFrameVersion = 4555

detailsWindowFrame = {{260, 320}, {920, 467}}

detailsWindowLeftFrame = {{0, 0}, {165, 350}}

detailsWindowViewIndex = 0

detailsWindowConfigurationsTabIdentifier = log

leftNavSelectedDisplayName = client

AdvancedWindowTabIdentifier = connectingAndDisconnecting

haveDealtWithSparkle1dot5b6 = 1

haveDealtWithOldTunTapPreferences = 1

haveDealtWithOldLoginItem = 1

SUEnableAutomaticChecks = 1

SUFeedURL = https://www.tunnelblick.net/appcast-b.rss

SUScheduledCheckInterval = 86400

SUSendProfileInfo = 1

SULastCheckTime = 2016-04-14 16:15:38 +0000

SULastProfileSubmissionDate = 2016-04-13 16:16:34 +0000

SUHasLaunchedBefore = 1

WebKitDefaultFontSize = 11

WebKitStandardFont = .Helvetica Neue DeskInterface

================================================================================

Tunnelblick Log:

*Tunnelblick: OS X 10.10.5; Tunnelblick 3.6.2beta06 (build 4555); prior version 3.6.1 (build 4543.4551)

2016-04-14 17:16:11 *Tunnelblick: Attempting connection with client using shadow copy; Set nameserver = 769; monitoring connection

2016-04-14 17:16:11 *Tunnelblick: openvpnstart start client.tblk 1337 769 0 1 0 1065842 -ptADGNWradsgnw 2.3.10

2016-04-14 17:16:21 *Tunnelblick:

Could not start OpenVPN (openvpnstart returned with status #226)

Contents of the openvpnstart log:

*Tunnelblick: openvpnstart log:

Loading tap-signed.kext

stderr from kextload: /Applications/Tunnelblick.app/Contents/Resources/tap-signed.kext failed to load - (libkern/kext) kext (kmod) start/stop routine failed; check the system/kernel logs for errors or try kextutil(8).

Unable to load net.tunnelblick.tun and/or net.tunnelblick.tap kexts in 5 tries. Status = 71

2016-04-14 17:16:11 *Tunnelblick: openvpnstart starting OpenVPN

jkbull...gmail.com

unread,

Apr 14, 2016, 12:35:03 PM4/14/16

to tunnelblick-discuss, edwar...@gmail.com, david...@datahug.com

No, you're seeing a different problem. You have two kexts already loaded that conflict with the Tunnelblick kexts:

125 0 0xffffff7f80a1d000 0x7000 0x7000 net.sf.tuntaposx.tun (1.0) <7 5 4 1>
126 0 0xffffff7f80a27000 0x7000 0x7000 net.sf.tuntaposx.tap (1.0) <7 5 4 1>

Tunnelblick wants to load its "tap" kext, but because the "net.sf.tuntaposx.tap" kext is already loaded, it can't.

See An OpenVPN log entry says "Tunnelblick: openvpnstart status #247: Error: Unable to load net.tunnelblick.tun and/or net.tunnelblick.tap kexts in 5 tries. Status = 71".

David Burke

unread,

Apr 14, 2016, 12:40:12 PM4/14/16

to jkbull...gmail.com, tunnelblick-discuss, edwar...@gmail.com

awesome, that solved it thanks

--

David Burke | Datahug | +353870934257
Download the B2B Sales Operations Playbook

arj...@samanvayfoundation.org

unread,

Apr 20, 2018, 5:45:53 AM4/20/18

to tunnelblick-discuss

Hi,

I recently started getting this problem (i think after a minor version update of macOS). I am on macOS High Sierra 10.13.4

I am using dev tap option.

As per the link https://tunnelblick.net/cKextLoadErrorHighSierra.html , as i understand i should get an option to approve the loading of kext but i am not getting any such option. I also tried going to System -> Security -> General but don't see any option to approve loading of any kext.

What can i do?

I tried changing dev tap to dev tun but i don't understand it very well and after changing that it connects to VPN but not able to connect internet or any machine on VPN.

Any help greatly appreciated.

Tunnelblick developer

unread,

Apr 20, 2018, 7:57:46 AM4/20/18

to tunnelblick-discuss

You should not change "tap" to "tun". That won't work and you should undo it.

According to Apple:

"This approval UI is only present in the Security & Privacy preferences pane for 30 minutes after the alert. Until the user approves the KEXT, future load attempts will cause the approval UI to reappear but will not trigger another user alert."

The "approval UI" is the bottom part of the "General" tab of the "Security & Privacy" System Preference and looks like this:

The "user alert" is this popup:

Here's what I recommend:

Restore your configuration to use "tap".
Restart your computer.
Try to connect (it will fail, presumably).
Click on the "Allow" button in System Preferences > Security & Privacy > General.

arj...@samanvayfoundation.org

unread,

Apr 21, 2018, 3:50:26 AM4/21/18

to tunnelblick-discuss

Thanks much for the reply.

Actually i had tried the things mentioned, that is restarting the computer and waiting for the Kext approval message. I have even tried uninstalling and installing tunnelblick to overcome the possibility of 30 min window having expired. Even tried installing another VPN client. For me, The Kext approval box doesn't seem to be coming up and doesn't show up in Security & Privacy either (within 30 mins too). One difference i noticed is that I am on the recently released version of MacOS, that is 10.13.4. I tried on my colleagues machine with 10.13.2 where the Kext approval shows up in Security & Privacy and on approving all works fine.

I see in the release notes of 10.13.4, which mentions

"No longer disables User Approved Kernel Extension Loading on MDM-enrolled devices. For devices with DEP-initiated or User Approved MDM enrollment, administrators can use the Kernel Extension Policy payload.",

but i am at a loss making sense of it and figuring out what should be my next step

https://support.apple.com/en-in/HT208533

I am using a rented laptop and don't know if its MDM-enrolled or DEP-initiated.

I also came across this on internet : https://www.techspot.com/news/74261-users-report-serious-stability-issues-macos-10134.html :(

Tunnelblick developer

unread,

Apr 21, 2018, 11:29:14 AM4/21/18

to tunnelblick-discuss

I wasn't suggesting that you try those things separately, I was suggesting that you try that specific sequence of things in that order.

The idea was that the restart would clear anything that is preventing macOS from showing the "approval UI". (The "user alert" will apparently never be shown again.) Then trying to connect would cause Tunnelblick to try to load the kext, and (according to Apple), that should cause the "approval UI" to appear in System Preferences > Security & Privacy > General.

It wouldn't hurt to do a "Safe Boot" instead of a normal boot.

It is certainly possible that your rented laptop is MDM managed, but I don't know how to find that out. There are instructions for "whitelisting" kext signers for MDM-managed Macs in several places on the Internet, so you could try those.

Most of the problems with 10.13.4 seem to have to do with getting the installation to complete. I'm not sure how relevant that is to this problem.

Reply all

Reply to author

Forward