New issue
Advanced search Search tips

Issue 905500 link

Starred by 24 users

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Feature



Sign in to add a comment

expose tun/tap access to the container

Project Member Reported by vapier@chromium.org, Nov 14

Issue description

some people have requested tun/tap access (i.e. /dev/net/tun) inside the container.  we should gather use cases and evaluate whether we want to expose this by default.

this is not about providing people a way to set up VPNs from the VM so the rest of the system can utilize it.  CrOS already supports VPNs directly and we're not going to build out replacements for it.

(and related, issue 834585 is about having the VM env respect the enabled VPNs)
 
Until issue 834585 is fixed, for many people Crostini is only useful if they can run a VPN within the VM. For that reason it should at least be available, and preferably without needing to enter dev mode.

This was at least working until the more recent updates. 

The latest beta 71.0.3578.49 which updated my Pixelbook today seems to have broken the "lxc config..." workaround in comment 25. Even though I am still in dev mode. I re-ran lxc config and /dev/net/tun is visible but when trying to start a VPN it throws an "operation not permitted" error. Sorry I don't have the exact error as I had to change to Stable to get my VPN working again. 

I first tried the dev channel and got the same error, so only stable 70.0.3538.76 seems to work at all presently. 


It worked on my HP Chromebook X2, same Beta version as you . I used open connect and I was able to maintain a connection as long as I executed the command as root. Did you try as root?

I did however notice that as of M71, I have to add the tunnel interface in termina every time that the VM restarts, instead of only have to do it one time after the container was created. Is this change by design?
this is only about collecting ideas for why people want tun/tap access, and then evaluating whether we actually move forward.

for general VPNs, we already have issue 834585.

if you're trying to expose tun/tap directly today and running into troubles, please use a mailing list or online forum for support instead.  bugs.chromium.org is for tracking work rather than general system support.
I personally like to have several non-defaultroute OpenVPNs going at a time, granting access to a variety of different data centres (as long as their routes don't overlap). tun/tap access in the VM is a nice way to accomplish this.
I like the current setup, provided the issue of having to recreate the tun interface after every reboot is resolved, at least.

It lets me connect to my work VPN under Crostini, and keep my activity on plain ChromeOS separate. I then use a different Chrome profile using the Linux version of Chromium, and keep the personal stuff on my personal profile on the main browser.
I also prefer to have access to tun in Crostini, as I run multiple vpns for work and prefer to keep them separate. 
When using my chromebook the easiest and most efficient way for myself (as well as help others) is to use the openVPN android app, import the VPN and connect.  At this point it should be as simple as open the terminal app and use the terminal to do various SSH tasks.  If the VM respected the system VPN and passed through it would be the most efficient due to the fact that the rest of the pixelbook (in our case) is already using a VPN and it makes it one easy config place for the user.  Please consider this solution for development.
does anyone have a use case that doesn't involve VPNs ?  as noted in comment #0, we already plan on making Crostini respect the system VPN setting.
I run multiple non-default route OpenVPNs at the same time, used for logging into remote machines using ssh etc. So I prefer to have  tun/tap access in the container.
#8 Chromeos doesn't support that many VPN settings. For my work access i need one that doesn't work with chromeos internal VPN settings (ikev1, xauth, psk). I would prefer a better VPN but most people cant't choose what their employer provides.

I have the same issue as Comment 10. My employer 'doesn't support' non-windows but I use Linux/ChromeOS on my Slate now.  On linux I used OpenConnect and it works great.

If I can't get the VPN working, it drastically cuts the usefulness of my Slate.  And my company won't license the Mobile VPN for the same reason.
Here's a different use case (still related to VPN though): I'd like to have a per-container VPN configuration, so that only applications running in a particular container would use VPN without affecting the rest of the system.

Sign in to add a comment