tun interface is broken, ChromeOS issue

[jasoncook]

Version 48.0.2546.0 dev (64-bit)
Platform 7583.0.0 (Official Build) dev-channel leon
Firmware Google_Leon.4389.61.46

When creating a tun interface for VPN connections the tun device is immediately destroyed. This means that VPN connections will fail. Example output below.

From ChromeOS:

localhost ~ # openvpn --mktun --dev tun0
Thu Oct 29 22:15:45 2015 TUN/TAP device tun0 opened
Thu Oct 29 22:15:45 2015 Persist state set to: ON
localhost ~ # ifconfig tun0 up
tun0: ERROR while getting interface flags: No such device

From inside the chroot:

(sana)jason@localhost:~$ sudo ip tuntap add dev tun0 mode tun
(sana)jason@localhost:~$ sudo ifconfig tun0 up
tun0: ERROR while getting interface flags: No such device

This is problem does not effect tap interfaces.

[DennisLfromGA]

Maybe this wiki article can help if you haven't seen it - Using Cisco AnyConnect VPN with openconnect

[jasoncook]

Thanks for the link. I've followed the wiki in the past and it worked perfectly.
The problem now is that the tun interface is unstable and is destroyed within a
few seconds of its creation. Not just in a down state, but completely removed
from the system. This behavior is consistent both inside and outside the chroot
so I've reported it to the Chromium team as well. Not sure how to further
troubleshoot this. Is there a debugger or a log I could look at for more
details?

On Fri, Oct 30, 2015 at 8:38 AM, DennisL < [email protected] [[email protected]] > wrote:
Maybe this wiki article can help if you haven't seen it - Using Cisco AnyConnect VPN with openconnect
[https://github.com/dnschneid/crouton/wiki/Using-Cisco-AnyConnect-VPN-with-openconnect]

—
Reply to this email directly or view it on GitHub
[https://github.com//issues/2215#issuecomment-152559108] .[https://github.com/notifications/beacon/AEXA8KrOaf7cH_8cgqT2o9hwVdgQU89kks5pA4aIgaJpZM4GYxPK.gif]

[unlikelylass]

This is affecting me as well.

crouton: version 1-20151104200003~master:2a1fc9da
release: jessie
architecture: amd64
xmethod: xorg
targets: xorg,cli-extra,e17,lxde,extension,xiwi,chrome,keyboard
host: version 7520.34.0 (Official Build) beta-channel peppy
kernel: Linux localhost 3.8.11 #1 SMP Tue Nov 3 22:59:57 PST 2015 x86_64 GNU/Linux
freon: yes

EDIT TO ADD:

Testing on a different chromebook running on stable shows this working:
crouton: version 1-20151013174138~master:488c9e21
release: sid
architecture: armhf
xmethod: xiwi
targets: xiwi,xorg,audio,core,cli-extra,e17,extension,lxde,keyboard
host: version 7390.68.0 (Official Build) stable-channel peach_pit
kernel: Linux localhost 3.8.11 #1 SMP Thu Nov 5 10:33:54 PST 2015 armv7l GNU/Linux
freon: yes

[emidln]

I encountered this as well. I'm not sure exactly how to tell Chrome OS to create a persistent tun0 interface, but I did notice that if I setup a fake openvpn connection through the network settings and try to connect to that, it will create a tun0 until reboot that my openvpn command in the shell can take advantage of.

[henkjan]

@jasoncook do you have the chromium bug report id? I would like to subscripe to the bug as i'm facing the same issue right now.

[jasoncook]

@henkjan I just officially reported it. Here you go.
https://code.google.com/p/chromium/issues/detail?id=557343

[ivr588]

using: acer C201P armv7

Hi, thought it might be worth mentioning that I see the same effect with any network interface. First they must be loaded/started in ChromeOS via the network applet, then the chroot can use it. Not tested with VPN, see the same effect with wlan0. To clarify, even with wlan0 up but not associated, I cannot from within the chroot associate with another base station. It connects then disconnects. If I change stations, I have to switch to ChromeOS to associate.

[pippo0312]

HI,
I think I found a reliable solution to make openvpn command working.
The tun0 interface is destroyed by the shill service which automatically kills the "useless" connections.

The solution is to enter the following commands before openvpn:

sudo stop shill
sudo start shill BLACKLISTED_DEVICES=tun0

the BLACKLISTED_DEVICES tells shill to ignore the "tun0" device.

I put in a script /usr/local/bin/openvpn2 all this, adding also a trick to change the DNS on the flight (to cure another problem with openvpn on chromebooks):

chronos@localhost /usr/local/bin $ cat openvpn2

#!/bin/sh -e
trap '' 2
# Stop shill and restart it with a nicer attitude towards tun0
sudo stop shill
sudo start shill BLACKLISTED_DEVICES=tun0
# Sleep 10 seconds to allow chromebook to reconnect to the network
sudo sleep 10
sudo openvpn --mktun --dev tun0
sudo sleep 3
# Add google DNS on top of current ones, since openvpn command does not do it
sudo sed -i '1s/^/# new DNS\nnameserver 8.8.8.8\nnameserver 8.8.4.4\n# old DNS\n/' /var/run/shill/resolv.conf
# Lauch openvpn, finally...
sudo openvpn --config $1 --dev tun0
# When ctrl-c is hit remove tun0 and cleanup the DNS
sudo openvpn --rmtun --dev tun0
sudo sed -i '/# new DNS/,/# old DNS/d' /var/run/shill/resolv.conf
trap 2

---

to open openvpn connection with a configuration file vpn.conf I give the command:

openvpn2 vpn.conf

hit ctrl-c to close the VPN
It works and it is very reliable.
Let me know if it solves also your problems!

[DennisLfromGA]

@pippo0312 - Great sleuthing and nice remedy. Maybe you could update the wiki with your new info. and solution...

[pippo0312]

wiki updated

[DennisLfromGA]

@pippo0312 - Great! Thanx.

[imain]

This works! However it now breaks android apps. I found you need to use:

sudo start shill BLACKLISTED_DEVICES="br0,tun0"

to make it work with them.

[DennisLfromGA]

@imain, Thanx. 👍
That may also be worthy of a wiki update.
-DennisL