Closed croiad closed 9 years ago
I am also having this issue, though I haven't even gotten the AnyConnect client to work once. I've shifted my efforts to OpenConnect, which you say won't work for you. I'm not familiar with Cisco Trojan CSD, I don't think my company uses it.
I'm not a coder or OS developer or anything, but from what I can tell, it's like you say. ChromeOS is handling the network driver, and the chroot can't get at it to add the TUN device that OpenConnect adds on my regular ubuntu box.
I'm interested in finding a way to connect to Cisco AnyConnect VPNs. If I can do that I can make this ChromeBook my main machine. Any help would be appreciated.
you can give this a try:
mattzog,
I have anyconnect working just not 100%. Using the command line I can get it to connect within a minute usually if I switch between Chrome OS and Ubuntu a couple of times. It is good enough that I have been using it exclusively for work.
What error do you receive when you try to connect? Are you using a version of the app provided by your company or did you download it? I found the version I used made a big difference.
croaid: The AnyConnect errors I get are, firstly: "AnyConnect was not able to establish a connection to the specified secure gateway. Please try connecting again."
After I click Close, I get: "The VPN client driver encounteced an error. Please restart your computer or device and try again."
I tried searching for help toubleshooting the AnyConnect client (thinking maybe I didn't have all the dependencies met or something), but didn't get anywhere. However this research did bring me to OpenConnect. I can use OpenConnect from the command line, but can't use it with network-manager. When I tried to get network-manager running, I got it installed and got nm-applet running, but when clicking on the nm-applet icon, it told me that network-manager wasn't running.
jack levy: There seems to be some helpful info at your link about vpnc having trouble with TUN devices. I'm going to see if I can configure openconnect with a TAP device.
I did try vpnc earlier, but our VPN device would require specific configuration to work with vpnc, and I'm not willing to ask my network admin to do that work just to accomodate my gadget fetish. Thanks for the link tho. I'll let you know if it helps.
all: I also tried setting up a ChromeOS VPN connection to work with our VPN, thinking that, if the VPN was connected in ChromeOS it'd work in the chroot. However, I don't think it's compatible with our VPN for the same reasons vpnc doesn't seem to work.
Thanks y'all! -mattzog
I am also having issues with this, been using the openconnect client rather than the Cisco one, but it still doesn't work. It's connected a handful of times, but usually what I get is this:
CSTP connected. DPD 30, Keepalive 20 Cannot find device "tun2" Cannot find device "tun2" Cannot find device "tun2" Cannot find device "tun2" SIOCSIFMTU: No such device Connected tun2 as 192.168.100.126, using SSL Established DTLS connection
I've tried using tunctl to create a tun0 (tun1, etc.) device manually: sudo tunctl -t tap1 -f /dev/net/tun
and then pointing openconnect to tun1 with the interface flag: sudo openconnect --script=/etc/vpnc/vpnc-script --interface=tun1 VPN_SERVER
but that fails with: CSTP connected. DPD 30, Keepalive 20 TUNSETIFF failed: Invalid argument
The weird part is that I have been able to connect occasionally, although I haven't been able to notice any pattern to it.
Anyone have any ideas? I don't have much experience with tap/tun devices or vpn networking, but I'd really like to get this working, this is the last thing preventing me from really being able to use the chromebook as a dev machine.
@bencpeters - I found that if I switched between Chromeos and Crouton a couple of times it would usually connect. I have not found a better resolution for this so I setup a dualboot on my Pixel. I was going to setup a little guide to doing it but haven't yet. If you decide to and need any assistance let me know.
I wonder if Shill is interfering in some way. You could set up a host-dbus dbus-monitor while playing with VPN to see if there's a particular shill-related event that results in the VPN working or not working.
I have exactly the same issue with openconnect as @bencpeters, running Arch Linux on the Samsung Chromebook Series 3.
@dnschneid - I'm happy to play with this & try to debug the VPN connection more if you've got any ideas... I don't have any experience with host-dbus dbus-monitor, so I'm not entirely sure what to look for. I ran exactly that command in the terminal in a headless session, but it wants a display to run, and I'm having some userspace (non sudo) issues getting my crouton install to work with xfce at the moment. Running that command with xfce started as root didn't give me much insight though - any tips on what exactly I'm looking for/other debugging steps?
Try running dbus-monitor | grep -i shill
from the crosh shell outside of the chroot.
@dnschneid When I run that command I receive:
Failed to open connection to session bus: Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DB US_SESSION_BUS_ADDRESS instead
Sorry, dbus-monitor --system | grep -i shill
@dnschneid - When I do that command nothing comes up. I am guessing that shill is not playing a roll in it not working. I did the dbus-monitor --system and connected a few times and found that when it will not connect (gives driver error) this shows up in the monitor:
signal sender=:1.3 -> dest=(null destination) serial=449 path=/; interface=org.chromium.flimflam.Manager; member=PropertyChanged string "UninitializedTechnologies" variant array [ ]
I'm getting basically the same error as @croiad:
signal sender=:1.6 -> dest=(null destination) serial=5957 path=/; interface=org.chromium.flimflam.Manager; member=PropertyChanged
string "UninitializedTechnologies"
variant array [
]
Did a little more looking at the logs. Interestingly, there is a shill-related message that gets written to /var/log/net.log when the connection works (nothing is written if the connection doesn't):
2013-09-08T20:05:44.337156-06:00 localhost shill: [0908/200544:ERROR:device_info.cc(542)] Add Link message does not have IFLA_ADDRESS!
Unfortunately, that doesn't really mean anything to me though!
I have found that if I enter chroot but do not start a graphical session I can connect with AnyConnect in the terminal every time. If I disconnect I have to exit and re-enter chroot to connect again.
Interesting findings. I actually usually run crouton headless, and I haven't been so lucky (mine does not always connect on a new chroot)...
Any more luck with AnyConnect?
Nope. Decided I was wasting too much time with it, gave up, and got a mba for remote work (there were a few other issues, such as lack of skype support too).
Still have the chromebook though, happy to test something out if you've got any ideas...
↓↓↓↓↓↓ Nice abuse of incidental binary compatibility! I doubt any other release or distro would work as well. Would you mind adding your method to the wiki?
sorry had to delete the entry found some errors, after a reboot it did not work anymore so i had to check again now it seems fine.
got openconnect working. i am able to use it even from outside of the chroot environment.
first i installed a precise chroot.
after that change inside the chroot and do apt-get install openconnect vpnc.
open a crosh shell, enter the command shell and switch to root sudo /bin/bash
then change to the directory where openconnect is installed:
cd /usr/local/chroots/precise/usr/sbin
after that you have to fix some library paths:
export LD_LIBRARY_PATH=/usr/local/chroots/precise/usr/lib/:/usr/local/chroots/precise/usr/lib/x86_64-linux-gnu/:/usr/local/chroots/precise/lib/:/usr/local/chroots/precise/lib/x86_64-linux-gnu/:${LD_LIBRARY_PATH}
now lets create some tun interface:
openvpn --mktun --dev tun1
and bring the interface up:
/sbin/ifconfig tun1 up
and now you can connect to your anyconnect vpn:
./openconnect vpn.hostname.com --no-cert-check --user=youruser --script=/usr/local/chroots/precise/etc/vpnc/vpnc-script --interface=tun1
for me this way i can ping our internal server, as well name resolution is working.
i hope i did not forget something, a small shell script should work better.
so far i tried also arch but had no luck to get openconnect working, chromeos does not like the libraries, looks they are maybe to new or compiled in another way.
i tried to connect lets say 20 times and it worked every time. did not try suspend.
i hope this helps, i use an intel based acer c720 maybe that makes a difference.
i will add it to the wiki as soon as i get the confirmation from some other side that its working. maybe again a mistake... to many hours spent in front of the problem.
a small note after you disconnect like ctrl + c take the interface down with:
ifconfig tun1 down otherwise the routing table looks really weired and you can't reconnect after that, oh and bring the interface up again if you want to connect. ;)
so need some sleep.
@faxe78 Thanks! I followed your instructions and got this working on my hp Chromebook 14.
has a script been made to do this? Although I do not use the software I may toss a script together to do this for you guys since the info is already provided and it should be fairly simple given the instructions have been tested.
@faxe78 I assume ./openconnect vpn.hostname.com --no-cert-check --user=youruser --script=/usr/local/chroots/precise/etc/vpnc/vpnc-script --interface=tun1 causes an interrupt in the session? if so the script could very easily ifconfig tun1 down for you. Is there a cleaner way to exit the session than ctrl^c? Perhaps an exit or logout command?
@faxe78 How would I do this if my chroot is encrypted? CD`ing to How can I access my encrypted chroot filesystem from inside a chronos shell (as rooot)? Trying to do this: cd /usr/local/chroots/saucy/usr/sbin
After chroot/saucy it is just a list of encrypted items.
@wergeld I dont think you can do it that way if it is encrypted. You would need to do this inside the chroot.
@edge226 Well, that is a downer. I am just trying to create a tun for use with CheckPoint VPN snx to use.
@wergeld there is probably a way to do it in the cli and just have it run nicely. I do not have a VPN to test on though.
@wergeld you can use mount-chroot and then access the unencrypted version at /var/run/crouton/usr/local/chroots/saucy/..., but only root has access to that.
@faxe78 Thanks! I followed your instructions and got this working on my c720 as well.
That's great! And it also works with other distributions (Archlinux on the Samsung Chromebook 3, for me), when you just create tun1 in the chrome-os shell, but run openconnect in the chroot.
crosh> shell
$ sudo su
# openvpn --mktun --dev tun1
# ifconfig tun1 up
# enter-chroot
chroot$ sudo /usr/sbin/openconnect -s /etc/vpnc/vpnc-script $HOST --interface=tun1
I hope others can reproduce that!
Personally, I have put the following commands in a script for the chronos user:
sudo openvpn --mktun --dev tun1
sudo ifconfig tun1 up
ssh -t mychrootuser@localhost /home/mychrootuser/bin/connect-vpn
sudo ifconfig tun1 down
You need to have sshd running for that to work. /home/mychrootuser/bin/connect-vpn
just contains the openconnect command (within the chroot, of course).
Thanks @fbreitwieser!!! :bow: Your instructions worked sucessfully on my Acer C720 chromebook. :+1:
crosh> shell
chronos@localhost / $ sudo sh -xc 'openvpn --mktun --dev tun1; ifconfig tun1 up; enter-chroot; ifconfig tun1 down; openvpn --rmtun --dev tun1'
(jessie)debian@localhost:~$ openconnect --interface tun1 # fill in your VPN settings here...
@croiad I was also able to use the :see_no_evil: Cisco Trojan (CSD) successfully with this method. Try it out! :rocket:
I found that @fbreitwieser's instructions also work successfully from inside my Debian Jessie chroot. So I no longer need to create the tunnel outside the chroot (in crosh shell) before entering the chroot. :smile_cat:
Oh, @sunaku, that's true. Nice, sometimes things turn out to be easy after all. As this was confirmed now that it works, I created a wiki page to describe how to connect to a AnyConnect VPN.
edit: Actually, it seems I have the same problem as originally described that sometimes I could connect, and other times not. So for me, the more stable solution is still to make the tun inside the Chrome OS. I'll update the wiki.
Thank you all for all of these helpful steps. I've successfully gotten openconnect to connect to the VPN within the chroot. However, whenever I do so, my entire internet connectivity just stops working and I can no longer resolve ANY web pages, within the vpn or without until I Ctrl+C
out of the VPN session.
crosh> shell
chronos@localhost / $ sudo su
localhost / # openvpn --mktun --dev tun1
Wed Jun 11 17:13:05 2014 TUN/TAP device tun1 opened
Wed Jun 11 17:13:05 2014 Persist state set to: ON
localhost / # ifconfig tun1 up
localhost / # sudo enter-chroot
Entering /usr/local/chroots/trusty...
Unknown username "whoopsie" in message bus configuration file
(trusty)<myusername>@localhost:~$ sudo /usr/sbin/openconnect -u <my username> -s /etc/vpnc/vpnc-script --interface tun1 <vpn host>
resolvconf: Error: /run/resolvconf/interface either does not exist or is not a directory
Connected tun1 as 10.1.40.236, using SSL + deflate
Established DTLS connection (using OpenSSL)
If at this point I attempt to go to http://google.com, I just get a cannot resolve DNS error.
Once I control+c
:
^CSend BYE packet: Client received SIGINT
resolvconf: Error: /run/resolvconf/interface either does not exist or is not a directory
Now DNS resolution works as expected.
And I'm not sure what the error about "whoopsie" is either?
is there an elegant way to copy the new resolv.conf from chroot out into host /var/run/shill/resolv.conf? I have to make openconnect ran into the background and copy the content out into chromeos. and then disable it when openconnect quits. It's quite a brute force approach.
i realized the 'elegant' way is don't install resolvconf at all. the vpnc-script will overwrite both of your /etc/resolv.conf in host and in crouton. once you install resolvconf, that behavior changes, then you start to miss nameservers.
You can also use this inside your chroot to create the TUN device:
/sbin/ip tuntap add dev tun0 mode tun
... so as to eliminate the dependency on OpenVPN.
This is just to show that there's nothing magical going on in the OpenVPN code, and maybe gives hope to the possibility that openconnect could simply be modified to take care of the TUN device itself.
In any case, openvpn --mktun ...
is working for me inside the chroot (openvpn package version 2.3.2-9ppa1~precise), so there's no need to use the openvpn binary provided by Chrome OS.
FWIW, OpenVPN tunneling also also seems to have this problem under ChromeOS+crouton -- it doesn't work unless you create a TUN device for it in advance, before trying to establish the OpenVPN tunnel.
Can anyone confirm all this? If so, I reckon the wiki should be updated.
recently openvpn --mktun
stopped working for me. the tun device does not persist for more than 10 sec even though I do have the persistent flag set. any advice on where I should look for where the problem is? I tried both jessie (debian) and trusty (ubuntu) distribution but the results are the same.
(liftoff)ezheng@localhost:~$ sudo /sbin/ip tuntap add dev tun1 mode tun
(liftoff)ezheng@localhost:~$ sudo ifconfig tun1 up
(liftoff)ezheng@localhost:~$ sudo ifconfig tun1 up
(liftoff)ezheng@localhost:~$ sudo ifconfig tun1 up
(liftoff)ezheng@localhost:~$ sudo ifconfig tun1 up
(liftoff)ezheng@localhost:~$ sudo ifconfig tun1 up
(liftoff)ezheng@localhost:~$ sudo ifconfig tun1 up
(liftoff)ezheng@localhost:~$ sudo ifconfig tun1 up
(liftoff)ezheng@localhost:~$ sudo ifconfig tun1 up
tun1: ERROR while getting interface flags: No such device
(liftoff)ezheng@localhost:~$
(liftoff)ezheng@localhost:~$ sudo ifconfig tun1 up
tun1: ERROR while getting interface flags: No such device
Do this in a shell in Chrome OS:
sudo stop shill
sudo start shill BLACKLISTED_DEVICES=tun1
Then the VPN client inside crouton should be able to use tun1 without interference from Chrome OS.
Thanks! great solution! but I ended up used this app from wiki and all problem seems to go away.
https://chrome.google.com/webstore/detail/cisco-anyconnect/jacdijibdjifphcecdielmekkmfdpgee
Edward Weiyi Zheng
On Mon, Feb 1, 2016 at 8:24 AM, Robert Fleming notifications@github.com wrote:
Do this in a shell in Chrome OS:
sudo stop shill sudo start shill BLACKLISTED_DEVICES=tun1
Then the VPN client inside crouton should be able to use tun1 without interference from Chrome OS.
— Reply to this email directly or view it on GitHub https://github.com/dnschneid/crouton/issues/235#issuecomment-178054595.
Hoping someone can give me some direction here. My company uses AnyConnect with the Cisco Trojan (CSD) which has stopped me from being able to get OpenConnect to work correctly so I have resorted to the Cisco AnyConnect App.
The App works perfectly the first time I launch it. It connects to my work network and I have no issues. After I disconnect I cannot ever reconnect. I receive the error "The VPN client driver encountered an error". This appears to be a common error with the Windows client but I cannot find anyone who has experienced it under Linux.
Even if I uninstall/reinstall the app, as well as delete every Cisco/AnyConnect folder I can find, it will give me the same error. The only solution I have found is to completely reinstall my chroot (not really a solution). After the reinstall it will work once again.
I believe it is creating a file, or modifying a file somewhere, but I cannot find it. Anyone have any suggestions?
I am currently running Raring.
Thanks
6/24 EDIT: After more testing it acts as if it does not have control over the network interface device. If I attempt to reconnect 5-10 times after it fails I will be able connect again. This leads me to believe that it is not a file that is being changed after install as I originally thought, but is a permission or access problem to a kernel component.
6/25 EDIT: I have come to the conclusion that I think my chroot and chromeos are battling for control of network devices. it is the only thing that I can find that could be causing the inconsistency that I am seeing. Sometimes it will connect fine, other times not. I have noticed the same behavior with the audio hardware within KDE(pulse). I am getting close to just dual booting so that it will work every time but haven't given up quite yet.
One plus is that when the chroot has control over the network device it never disconnects. All I need is a way to focus control to the chroot long enough to make the connection, then I would not have to worry about it. I have tried to restart the networking daemons from within the chroot thinking that might do it, but I cannot seem to get that to work.
Any Ideas from anyone?