Using Cisco's tun.kext kernel extension instead of tuntaposx's
Pete
been simultaneously connected to a PPTP tunnel and two OpenVPN
tunnels, all with specific subnet routes. The PPTP VPN was my
coprorate one, and they just deactivated it in favor of Cisco
AnyConnect SSL VPN.
So I had to install the AnyConnect client, and ran smack into the
issue of conflicting kernel extensions between that and tuntaposx
(issues 18 and 41, and in tuntaposx's FAQ). Pragmatically, I'd just
like it fixed by someone, even if it isn't the community/company that
caused the problem.
Since Cisco isn't responding to the tuntaposx developer's dialog, and
he is unable or unwilling to fix the issue in tuntaposx, we must move
up the stack. Cisco is closed source, and a lumbering, unresponsive
giant. Their official response to the conflict is to uninstall
OpenVPN. Thanks for that!
That leaves OpenVPN. There are a multitude of open bugs and feature
requests for the open source project with no followup, so I don't
expect much there. I'm thinking here's a chance for Tunnelblick to
stand out as the only OpenVPN client to coexist with Cisco...
Is it possible for the openvpn client that Tunnelblick uses to use the
Cisco kernel extension if it is loaded? I don't know how similar the
API is, what it looks like, or even if it's documented anywhere, but
if the client had the smarts to use it if it was present, the conflict
just goes away.
Unfortunately, using Cisco's kernel extension would expose Tunneblick
to the whims of Cisco's development staff and their upgrade/feature
schedule. And the OpenVPN crowd tends to trust open source more than
closed/proprietary. But if a user has installed the AnyConnect
client, they have already acknowledged that Cisco is trustworthy
enough to run code on their system. Plus, looking at the filesystem
dates of Cisco's tun.kext, it doesn't appear to be updated too
frequently.
I'm new to Macs, and not a mac developer yet, so don't have the
expertise to develop/test/submit a patch. Can anyone who does have
the expertise please weigh in?
IANAL; would there be legal implications?
jkbull...gmail.com
tap kexts. It is available in the Files section of this discussion
group under the name "Tunnelblick-Not-load-tuntap.app.zip".
If this works for you, I could make this controlled by a preference,
or perhaps "see" that the Cisco kexts are loaded and go on from there.
Let me know.
If it doesn't work (i.e., if OpenVPN can't work with the Cisco kexts),
I don't think there's much more Tunnelblick can do.
If you are bothered by the warning about the name of Tunnelblick
having been changed just rename it (after unzipping) back to
Tunnelblick.app.
I will remove the upload in a day or two (or when you post back).
Pete
cannot allocate TUN/TAP dev dynamically (see below). Would have been
nice, but I guess it's too easy! Thanks for posting it.
How about this idea then. Since the two kernel extensions cannot be
loaded at the same time, can the loading/unloading of tun.kext and
tap.kext by Tunnelblick be broken out into scripts (eg. [tun|tap].[up|
down].osx.sh)? And can those scripts be called when Tunnelblick is
about to bring up a connection or after taking one down?
That would allow the Cisco extension to be loaded right up to the time
the user needs an openvpn tunnel, where it can be unloaded by the
tun.up.osx.sh script. Once no more tunnels are using the tuntaposx
device, the tun.down.osx.sh script would unload it and reload Cisco's
extension. Plus, if other vendors' VPN clients do the same thing,
they too could be covered by this method.
A couple of potential gotchas: if (un)loading the kernel extension
fails, the script should probably return an error. It may be safe to
ignore it on unloading, but if loading fails, there's no sense
continuing to bring the tunnel up. Loading could fail if the Cisco
client is active and the extension cannot be unloaded. It would also
fail if already loaded, but that can be detected so that no error is
returned.
Also, since these would have to run as root, permissions/ownership
would have to be controlled, similar to how the existing
client.*.osx.sh files are.
I don't think either of those are deal killers. Could you please
expand on the previous build by calling the named scripts mentioned
above before/after bringing a tunnel up? Give me a couple days, and
I'll come up with scripts that should work with or without the Cisco
client installed. Scripting I can do... 8-)
--
Pete
not working:
2010-04-08 17:08:04
2010-04-08 17:08:05 SENT CONTROL [analyst-server]:
'PUSH_REQUEST' (status=1)
2010-04-08 17:08:05 ifconfig 172.31.5.234 172.31.5.233'
2010-04-08 17:08:05 OPTIONS IMPORT: timers and/or timeouts modified
2010-04-08 17:08:05 OPTIONS IMPORT: --ifconfig/up options modified
2010-04-08 17:08:05 OPTIONS IMPORT: route options modified
2010-04-08 17:08:05 ROUTE default_gateway=10.1.100.1
2010-04-08 17:08:05 Cannot allocate TUN/TAP dev dynamically
working:
2010-04-08 17:09:24
2010-04-08 17:09:25 SENT CONTROL [analyst-server]:
'PUSH_REQUEST' (status=1)
2010-04-08 17:09:25 ifconfig 172.31.5.234 172.31.5.233'
2010-04-08 17:09:25 OPTIONS IMPORT: timers and/or timeouts modified
2010-04-08 17:09:25 OPTIONS IMPORT: --ifconfig/up options modified
2010-04-08 17:09:25 OPTIONS IMPORT: route options modified
2010-04-08 17:09:25 ROUTE default_gateway=10.1.100.1
2010-04-08 17:09:25 TUN/TAP device /dev/tun0 opened
2010-04-08 17:09:25
2010-04-08 17:09:25 /sbin/ifconfig tun0 delete
2010-04-08 17:09:25 NOTE: Tried to delete pre-existing tun/tap
instance -- No Problem if failure
2010-04-08 17:09:25 /sbin/ifconfig tun0 172.31.5.234 172.31.5.233 mtu
1500 netmask 255.255.255.255 up
2010-04-08 17:09:25
2010-04-08 17:09:25 /sbin/route add -net 172.31.5.0 172.31.5.233
255.255.255.0
2010-04-08 17:09:25 Initialization Sequence Completed
--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To post to this group, send email to tunnelbli...@googlegroups.com.
To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en.
jkbull...gmail.com
Cisco tunnel to be open simultaneously, unless Cisco or OpenVPN
changes their tun/tap interfaces. So you can't get what you really
want -- simultaneous tunnels.
I don't like the idea of Tunnelblick unloading other programs' kexts
-- it seems impolite, to say the least. And it isn't clear that they
could (in general) be reloaded properly, although maybe it could be
done by reading the launchctl plists (if that's how they're started in
the first place).
I suggest that you write and use a script that does the following:
1) Unloads the Cisco kexts
2) Starts Tunnelblick (using the "open" command?). Have your
configuration set to "Automatically connect on launch". Tunnelblick
will load its kexts.
3) Waits until Tunnelblick quits. Tunnelblick will unload its kexts
before exiting.
4) Loads the Cisco kexts
So instead of letting Tunnelblick run all the time and connecting/
disconnecting to open/close the tunnel, launch your script to open the
tunnel, and quit Tunnelblick to close the tunnel. At most it's a
couple of seconds to launch Tunnelblick (as opposed to clicking
"Connect").
If you do write such a script, please share it!
Pete
Cisco's extension and, if successful, launches a sub-shell which waits
1 second before launching a background shell that opens tunnelblick as
the original user, waits for it to exit, and reloads Cisco's
extensions. It's a little hard to read because I had to play with the
subshells a little to leave just a single shell running as root
waiting for open to close.
Since it's so short, I'll put it inline rather than in the Files
section of the forum. It must be run from sudo.
#!/bin/bash
kextunload -b com.cisco.cscotun && ( sleep 1; ( sudo -u $SUDO_USER
open -W /Applications/Tunnelblick.app; kextload -b com.cisco.cscotun
> /dev/null ) & )
You're right in that I wouldn't be able to open tunnels from both
products simultaneously. However, with this script, I have to switch
to the CLI, run the script with sudo, enter my password, and then go
to the Tunnelblick GUI to select which tunnel I wish to bring up
(assuming I have more than one. At that point, I might as well stick
with the MacPort openvpn package and not even install Tunnelblick. Or
run one of them from a VM.
Since the Mac is primarily a GUI-driven platform, I maintain that it
would be nice to have both GUIs up simultaneously and to be able to
use them immediately to open a tunnel, even with the understanding
that if one has an active connection, the other will give a failure
when trying to connect.
And I agree that it is impolite to just up and unload someone else's
kernel extension, but understand that it will not unload if a tunnel
is up and the extension is in use. I tested this assertion on both
com.cisco.cscotun and foo.tun (tuntaposx) kernel extension bundles.
Plus we're dealing with impolite kernel extensions to begin with,
since they don't politely coexist. Plus, if Cisco's client only
loaded the extensions when the GUI is started, as Tunnelblick already
does, this wouldn't be an issue, as long as only one GUI was running
at a time.
I was going to suggest commenting out the portion of the tun.[up|
down].osx.sh scripts that fiddled with the Cisco kext on the released
product anyway, if this thread makes it that far. Accompanying
comments would warn that it is for advanced users only.
Please reconsider. I'd still like to see a version of Tunnelblick
that calls scripts to load/unload its kernel extensions on demand.
I'll write the up/down scripts and test that it has feature parity
with the base release.
Thanks much,
--
Pete
Pete
was called based on the config file for the connection, then it could
indeed coexist with a connected Cisco tunnel, assuming the OpenVPN
tunnel used the tap device instead of tun. Foo.tap doesn't conflict
with Cisco's extension.
Just a though...
Pete
one long line. Here's one broken up into several lines so it doesn't
wrap.
Kee Hinckley
On Apr 9, 2010, at 3:53 PM, Pete wrote:
> I have just such a script already developed and tested. It unloads
> Cisco's extension and, if successful, launches a sub-shell which waits
> 1 second before launching a background shell that opens tunnelblick as
I have always disabled Cisco's extensions and hand-loaded them when I needed them. They used to (and perhaps still do, I haven't bothered to check) have a serious problem with mobile laptops. Changing my IP address as I moved from location to location and they wouldn't work until unloaded and reloaded anyway.
Pete
TunnelBlick to unload the extensions on demand... 8-)
jkbull...gmail.com
projects: (1) configuration "packages" and (2) separating Tunnelblick
into a daemon and a GUI (so it can control VPN servers as well as it
controls clients). But that will be weeks, perhaps months. It's on my
list.
> However, with this script, I have to switch to the CLI,
> run the script with sudo, enter my password, and then
> go to the Tunnelblick GUI to select which tunnel I
> wish to bring up (assuming I have more than one.
If you have multiple configurations, then of course you'll have to
select which one you want to start. But you should be able to run a
script to unload-the-kexts/start-Tunnelblick/load-the-kexts, without
using sudo from the command line (which requires your password to be
entered).
Make three scripts:
script A, which unloads the kexts,
script B, which loads the kexts
a main script, which does something like:
sudo A
sleep
start Tunnelblick
wait for Tunnelblick to quit
sudo B
Use the trick described at
http://macosx.com/forums/software-programming-web-scripting/301242-making-executable-run-root-every-time.html
to let the sudo command run the A and B scripts without requiring
passwords by adding entries to /etc/sudoers.
And use either of the tricks at
http://www.macosxhints.com/article.php?story=20010827215428108
to have a double-click on the main script in Finder run it in a
Terminal window.
jkbull...gmail.com
like Kee Hinckley, disable the Cisco tun/taps, then use a script to
start the _Cisco_ VPN:
* Load Cisco kext(s)
* Run the Cisco VPN
* Unload Cisco kext(s)
This would, in effect, make the Cisco software play nicely with others
(and not just Tunnelblick).
Pete
> Instead of scripts for _Tunnelblick_, another possibility would be to,
> like Kee Hinckley, disable the Cisco tun/taps, then use a script to
> start the _Cisco_ VPN:
True. Especially since it's Cisco that's not playing nicely to begin
with... Which one I script may depend on which VPN I use more often.
I could also write a little C program to load/launch/unload, make it
setuid root, and use that to launch one or the other. I don't know
that the average user is comfortable with either solution, though,
after seeing how many truly horrid howto's there are out there on how
to setup openvpn. 8-/ Tunnelblick's deployment feature is looking
better all the time!
In the mean time, I'm reconfiguring the servers to use the tap
interface, manually loading tap.kext, and using the version you posted
earlier. That allows me to have both VPN types up concurrently, which
is ultimately what I wanted to begin with. If I can, I'll download
source and try coming up with a patch to load/unload the devs via
scripts.
Thanks all for the great discussion!
Pete
this after all. Most of the changes were localized to openvpnstart,
which made things easier. I've uploaded kext-dev-scripts-patch.zip
which has a patch for openvpnstart.m, the two device.[up|down].osx.sh
scripts that are called instead of calling kextload and kextunload
directly, and an optional patch to VPNConnection.m that attempts to
unload the extension after a VPN is disconnected.
Without the last patch, Cisco's extension doesn't get reloaded (so
their client cannot connect) until Tunnelblick is closed. That may
make it appear to be Tunnelblick's fault that Cisco's client to
fails. Hence, I'd recommend the Cisco stuff be commented out (or
outright removed) before released. Someone with the skill/
understanding to uncomment or edit the scripts would understand the
interactions and how Tunnelblick is working around Cisco's
shortcomings.
By ignoring the initial loadKexts call without a config file, it waits
until start is called with a configPath to determine whether tun or
tap should be loaded. This allows tap VPNs to be active while Cisco's
client is, and my world returns to normal! And even if using a tun-
based VPN with Tunnelblick, this allows first come first serve
access. The client late to the game somewhat gracefully errs out,
since a kext in use cannot be unloaded.
jkbull...gmail.com
consider adding this ability to the trunk when I've finished some
other projects. In the meantime, you (and anyone else who needs it now
and can compile) can used your patches, so that's great. I will look
at the issue in more detail after I finish packages and "daemonizing"
Tunnelblick, both of which involve changes to openvpnstart
Here are my initial thoughts, in no particular order. Please don't be
discouraged or annoyed or take them as a criticism of your work -- I'm
going into a lot of detail so I can refer back to this discussion when
I reconsider this later:
* Should Tunnelblick do this with scripts or with compiled code? Can
compiled code avoid the "sleep 2"? And why is that needed anyway?
* Even if Tunnelblick doesn't do this, should Tunnelblick always
unload its tun/tap kexts dynamically (when connections are destroyed)
instead of doing it when the application quits?
* This won't work with deployed versions of Tunnelblick. The
deployment mechanism cannot involve changes to anything outside of
Resources/Deploy because only /Resources/Deploy is preserved when
Tunnelblick is reinstalled or updated. Someone who modified the
scripts (to either include or exclude the unloading of the Cisco
kexts) and then updated or reinstalled Tunnelblick would lose their
modifications. So need to detect and use similar scripts that are in
Deploy and document that.
* Tunnelblick packages (see http://code.google.com/p/tunnelblick/wiki/PackagesProposal)
will need to be similarly modified to allow packages to include these
scripts.
* I'm not sure the tun/tap detection is robust. What about whitespace
before and after "dev"? (Although perhaps OpenVPN doesn't allow any.)
Does OpenVPN have a mechanism for allowing multiple commands on a
single line? What happens if a configuration file has "dev xxx"
instead of "dev tun" or "dev tap"? Until now, Tunnelblick has avoided
parsing the OpenVPN configuration file. Is the ability to have
simultaneous Cisco/OpenVPN connections worth any problems the parsing
might introduce?
* I want to consider what (if anything) happens if it tries to unload
a kext while another connection is being started or restarted. Race
conditions?
* What (if any) error messages are sent to the console log when a kext
is in use and we try to load/unload it?
* I might want to make the unloading of the Cisco scripts controlled
by a preference, perhaps a per-configuration preference, and pass a
flag to the scripts. I would want to make it available to ordinary
users and not encourage people to muck about in the scripts. And/or
have Tunnelblick detect the presence of "conflicting" tun/tap kexts
(from Cisco, Viscosity, ???) and notify the user and let them decide
what to do about it? Do this at startup and/or when a connection is
made?
* Should Tunnelblick do this with scripts or with compiled code? Can
compiled code avoid the "sleep 2"? And why is that needed anyway?
* Does the method for unloading/loading the Cisco kexts work with
older versions of the Cisco client? With Tiger and Leopard? What about
using the "sudo /System/Library/StartupItems/CiscoTUN stop" method to
unload instead? Do any of these methods cause OS X to lose the cache
of kexts used at computer startup?
* Is there a way to avoid the "sleep 2", which builds in a two-second
delay in making the connections? Is two seconds always enough?
* Are there any OS X caching issues that affect this? (I've run into
such caching problems in similar contexts.)
Pete
community... 8-)
> * Should Tunnelblick do this with scripts or with compiled code?
Scripts are much easier to change on the fly. I worked on compiling
the logic into openvpnstart at one point, but don't know objective-C
well enough to do what one grep/cut command in the script does. And,
for an end user to change (i.e. for some other VPN client that doesn't
play nice), it's hard to beat a script. The draw back is that the
script is run as root, so parameters have to be desanitized and the
path and file ownership matters.
> Can compiled code avoid the "sleep 2"? And why is that needed anyway?
> Is two seconds always enough?
At one point, I tried to load an extension immediately after its
conflicting extension was unloaded, and I think I saw that it failed.
I can review it and see if it is really required. I left it in as a
safety measure to give things time to "settle." I'll test it without
and let you know.
> * Even if Tunnelblick doesn't do this, should Tunnelblick always
> unload its tun/tap kexts dynamically (when connections are destroyed)
> instead of doing it when the application quits?
I think it's probably a good practice. If Cisco's client did this, we
wouldn't be jumping through hoops to do it for them... It helps that
kextunload fails to unload a device if it is still in use.
> * <snip> need to detect and use similar scripts that are in
> Deploy and document that.
Agreed. I haven't used the deploy mechanism, so didn't do any
planning for that. It would make sense to prefer a personalized
script in the deploy folder first if available.
> * Tunnelblick packages (see http://code.google.com/p/tunnelblick/wiki/PackagesProposal)
> will need to be similarly modified to allow packages to include these
> scripts.
Again, this is a feature I'm not personally familiar with. I did see
that permissions/ownership were checked for all scripts ending
in .osx.sh in the Resources folder, which is why I stuck with that
convention.
> * I'm not sure the tun/tap detection is robust. What about whitespace
> before and after "dev"?
You're right; that part is a bit of a hack. I tried using 't' as a
field delimiter since both current device types start with that, but I
didn't get too far with that. Perhaps awk would work better than grep
and cut.
> Does OpenVPN have a mechanism for allowing multiple commands on a
> single line?
Not to my knowledge. It does have the ability to specify a particular
device node, eg. tun0 or tap1, which is why I don't just parse out the
whole word, just the first three chars.
> What happens if a configuration file has "dev xxx"
> instead of "dev tun" or "dev tap"?
Not sure what you mean here; a third device type that hasn't been
implemented yet? I'd worry about that when it happens rather than
planning for a future scenario. Layers 2 and 3 are covered by tap and
tun, and I don't see an immediate need for other layers.
Perhaps, if parsing the file doesn't result in either "tun" or "tap",
we should output a warning and try to load both extensions. That
would fail gracefully, and with the same behavior that is currently
implemented, meaning if there are no competing VPN clients, it would
just work.
> <snip> Is the ability to have simultaneous Cisco/OpenVPN connections
> worth any problems the parsing might introduce?
It is for me, but I'm a small subset of users who actually want
simultaneous connections from different VPN clients.
Ultimately, this patch is only meant to give me the ability to do
this. If you took out all the parsing and extra cscotun handling and
just made the up script load both extensions and the down script
unload them, you should have feature parity with the stable release,
except that advanced users would be able to edit the scripts to do the
fancier handling.
> * I want to consider what (if anything) happens if it tries to unload
> a kext while another connection is being started or restarted. Race
> conditions?
This may be acceptable, as the connection would just fail when it gets
up to the point when it tries to actually use the device. Seeing this
failure, the user would most likely just try the connection again,
which should reload the extension so that it works.
Ooh. I didn't test reconnect options; would a VPNConnection:disconnect
followed immediately by a connect trigger this? I don't think so, as
it doesn't disconnect in the background, so should wait until it's
unloaded before it tries another connect. I did notice that there
were multiple unload attempts in the console log, though, with the
second attempt failing because it was already unloaded. I didn't dig
into the code enough to understand why VPNConnection:disconnect was
being called more than once.
> * What (if any) error messages are sent to the console log when a kext
> is in use and we try to load/unload it?
We get these messages, which I think Tunnelblick should intentionally
ignore.
4/13/10 10:39:02 AM [0x0-0x1a01a].com.openvpn.tunnelblick[689] /sbin/
kextload /Applications/Tunnelblick.app/Contents/Resources/tap.kext
4/13/10 10:39:02 AM kernel tap: won't unload, at least one interface
is busy.
4/13/10 10:39:02 AM [0x0-0x1a01a].com.openvpn.tunnelblick[689]
kextunload: unload kext /Applications/Tunnelblick.app/Contents/
Resources/tap.kext failed
4/13/10 10:39:02 AM [0x0-0x1a01a].com.openvpn.tunnelblick[689] Error:
Unable to unload tun and/or tap kexts. Status = 1
4/13/10 10:39:02 AM [0x0-0x1a01a].com.openvpn.tunnelblick[689] Error:
Unable to unload tun and/or tap kexts. Status = 1
> * I might want to make the unloading of the Cisco scripts controlled
> by a preference, <snip> ... notify the user and let them decide
> what to do about it? Do this at startup and/or when a connection is
> made?
That's up to you. I don't think I would, as you've got too many other
vendors with too many versions, and I think it would become a
maintenance headache. Based on my searching on google, this issue
isn't that common, and if someone is trying to bring up more than one
concurrent VPN from different vendors, they're probably advanced
enough to at least edit scripts (or should be). Make it too easy, and
you might be encouraging people to get themselves into trouble.
> * Does the method for unloading/loading the Cisco kexts work with
> older versions of the Cisco client? With Tiger and Leopard? What about
> using the "sudo /System/Library/StartupItems/CiscoTUN stop" method to
> unload instead? Do any of these methods cause OS X to lose the cache
> of kexts used at computer startup?
I haven't tested with other versions. I'm developing on 10.5.8 with
AnyConnect v2.4.1012 (latest that supports 64-bit Snow Leopard), and
will test on 10.6 as I roll this out to my immediate group at work.
Again, I'm not convinced you'll want to get into the maintenance
requirements of officially supporting compatibility with any and all
other VPN clients...
Calling the StartupItem script would work as well, although all it
does on my release is call kextload or kextunload. Since it doesn't
fiddle with the StartupItem, it shouldn't affect the cache, to the
best of my knowledge.
> * Are there any OS X caching issues that affect this? (I've run into
> such caching problems in similar contexts.)
I'm not familiar enough to give an opinion on this.
I did notice that, if I had an OpenVPN tun interface up and attempted
to bring up a Cisco tun interface, the Cisco client would fail fairly
quickly because it couldn't access the device, but the GUI would then
repeat some errors into the console log every five seconds until the
Cisco extension was loaded again. Another sign of Cisco developing as
if they're the only VPN vendor in the world.. *sigh* Not a big
problem, but it does clutter up the log unnecessarily.
There's also an issue with something that Cisco's client puts in place
blocking access to my OpenVPN tunnel unless I bring my OpenVPN tunnel
up first. Its not firewall related, as sudo ipfw flush doesn't fix
it. Until I figure it out, I'll just restart Cisco's tunnel if I need
to.