Just a side note, arc vpn integration on the dev channel 67.0.3396.26 is broken even on my lenovo yoga chromebook 4th gen. So it's not only crostini related. Btw, crostini is not even active on my platform yet.

I use zerotier VPN, which still works inside android and even inside  GNUroot (I mean that I can access my remote devices while running a browser inside GNUroot) but neither chrome, nor the file app can use the android VPN. On the beta channel everything was ok a couple of weeks ago.

@Luca may be right. I can confirm that ARC VPN Integration is also broken on the Pixelbook. This is also the case on 67.0.3396.26

Regarding chrome OS - android VPN integration, it's been fixed in the latest dev channel unpdate Mozilla/5.0 (X11; CrOS x86_64 10682.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3431.0 Safari/537.36

I can't say anything about Crostini, because it's not here yet for my device.

Still not fixed on Crostini instances but fixed on ChromeOS

Confirming that this is still not fixed for Crostini instances on the Samsung Chromebook Plus.  

+1 for this, please address, because VPN is critical piece.

Just a little more info - if you create a VPN connection using a .onc file (i.e. without using ARC), traffic out of the crostini container doesn't route down the VPN tunnel (as of today with the latest dev updates on Pixelbook).

I'm running Version 69.0.3464.0 (Official Build) dev (64-bit) on a Pixelbook with a Build date of Tuesday, June 19, 2018. Still experiencing this issue.

Not being able to route traffic from the container through VPN significantly limits my ability to work remotely.

Probably need DNS configuration to propagate into the VM for this to work.

Issue persists in Chrome Dev 69.0.3486.0

Please prioritize this issue - it's critical for users who want to use containers in a corporate environment where VPNs are used for any form of access.

+Sunil for product-side prioritization.

Aside from the DNS issues, it's clear that traffic isn't routed through the VPN when it comes from the VM. At a minimum I think we need https://chromium-review.googlesource.com/c/aosp/platform/system/connectivity/shill/+/1141066 to correctly route traffic from the crosvm user.

+abhishekbh, ejcaruso aside from this is there anything obvious that's missing?

In 69.0.3494.0 it appears that ARC VPN Integration is broken in Android again, and Crostini VPN support still does not work.

Is there any update on the progress of this? This is a deal maker/breaker for enterprise.

69.0.3497.14 still broken

Please star the issue instead of leaving a comment if you're affected.

same issue in pixelbook 69.0.3497.21. 
Pls fix it. I can not work without VPN

Similar issue but different use-case. I depend on my internal corp nameserver to resolve internal server names. I can clobber (from within the container) /etc/resolv.conf to point to my internal nameservers. To make this successful, I have to put in a hack-y loop, running as root, to cp a fixed up resolv.conf to /etc/resolv.conf every 30 seconds.

Is there a work-around until this issue is fixed? It is preventing me from using my Pixelbook's linux environment for development through my company's vpn.

So, I am running Version 70.0.3524.2 (Official Build) dev (64-bit) on my PixelBook, and I have my VPN entries back and working.

In addition, my android based VPN solution is working for android and Chrome access, but not Linux containers (as is to be expected for now).

x2 with the above ^

I was running OpenVPN from a chronos window as a work around prior to the update 70.X that is referenced above. That worked flawlessly for me.

For further clarification... I am still not able to use the OpenVPN that I use on Chrome OS (70.0.3524.2) within the Linux containers and trying to find a way to either use OpenVPN in the container directly or preferrably share the OpenVPN connection at the Chrome OS layer to the linux container.

There is a way to run the OpenVPN in the container directly. 

In Crosh: Start the Termina
> vmc start termina
> lxc config device add penguin tun unix-char path=/dev/net/tun

This will create the tun device on the container and enable openVPN to run without any issues within the crostini container. 

Thanks, commenter #25.  I knew that.  I am waiting for integration of the container networking with the host VPN solutions.  From what I understand, it is in process, but I am not sure on when it will land.

no need to thank, comment was meant for commenter #24 that based on his comment he sounded like he was not aware of a way of running openVPN within crostini. 

 Issue 863757  has been merged into this issue.

There's been no update on this issue in a couple of months. Can we get an update on progress? Is a solution being actively developed?

This is a major blocking issue for me, and many professional users. I can't use crostini for work without VPN support.

Just a question here, I am basically having a related issue.
There is currently no way supported manner to enable inbound UDP or TCP connections from the host's network-connections into Crostini containers.
This also make using Eve and other 'books fairly limited from a developer perspective. Should this issue be tacked on here, or should another issue be created?

[Outbound TCP is fine, and outbound UDP is okay, and inbound UDP can occur to same-process via kernel-based UDP pin-holing]
But I think these are a far cry from what developers need to do many specific dev tasks.
I am doing SIP development, and this limitation sort of renders Eve/Crostini out of the picture for UDP/VOIP development. 

this bug is only about containers respecting existing VPN connections.  any other topic/request should be a new bug.

Hi all, it would at least be very useful if the workaround-fix mentioned on #Comment 25 was implemented as default, so that we can start openvpn using the debian version inside Crostini. Manually executing that makes it work perfectly fine for me inside Crostini, although it makes me run:

- two different openvpn clients , one on main ChromeOS, the other inside Crostini
- stop / start vmc and run lxc config command every time I need it again.... 

Hi,

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 present. 

as i mentioned, this bug is not about tun/tap access, or exposing it to containers.  this is only about the VMs utilizing the VPN settings configured by CrOS itself.  if you want to discuss direct tun/tap functionality, please use issue 905500 instead.

 Issue 918228  has been merged into this issue.