New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 198 users

Issue metadata

Status: Assigned
Last visit > 30 days ago
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocked on:
issue 829192

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Issue 834585: ChromeOS Containers do not respect "ARC VPN integration"

Reported by, Apr 19 2018

Issue description

UserAgent: Mozilla/5.0 (X11; CrOS x86_64 10539.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3383.0 Safari/537.36
Platform: 10539.0.0 (Official Build) dev-channel eve

Steps to reproduce the problem:
1. Enable the "arc-integration" flag
2. Setup any Android VPN and connect to a VPN Server
3. Setup a new container
3a. vmc start dev
3b. --container_name=stretch --user=kmyers --shell
4. Install a web browser in the container and attempt to access a website that shows your IP address 

What is the expected behavior?
Your internet traffic should be going through the VPN 

What went wrong?
Traffic does not route through the VPN

Did this work before? N/A 

Chrome version: 67.0.3383.0  Channel: dev
OS Version: 10539.0.0
Flash Version: 

Many corporate environments require accessing secure content over a VPN but as containers do not seem to route traffic through a VPN, it may limit its use within enterprises.

Comment 1 by, Apr 19 2018

Components: OS>Systems>Containers Platform>ARC

Comment 2 by, May 1 2018

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.

Comment 3 by, May 1 2018

@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

Comment 4 by, May 19 2018

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.

Comment 5 by, Jun 2 2018

Still not fixed on Crostini instances but fixed on ChromeOS

Comment 6 by, Jun 6 2018

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

Comment 7 by, Jun 7 2018

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

Comment 8 by, Jun 8 2018

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

Comment 9 by, Jun 26 2018

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.

Comment 10 by, Jun 26 2018

Components: Platform>Apps>ARC OS>Systems>Network

Comment 11 by, Jun 27 2018

Blockedon: 829192
Labels: Proj-Containers
Probably need DNS configuration to propagate into the VM for this to work.

Comment 12 by, Jul 13 2018

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.

Comment 13 by, Jul 13 2018

+Sunil for product-side prioritization.

Comment 14 by, Jul 16 2018

Status: Assigned (was: Unconfirmed)

Comment 15 by, Jul 17 2018

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 to correctly route traffic from the crosvm user.

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

Comment 16 by, Jul 27 2018

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.

Comment 17 by, Jul 30 2018

69.0.3497.14 still broken

Comment 18 by, Jul 30 2018

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

Comment 19 by, Aug 6

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

Comment 20 by, Aug 6

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.

Comment 21 by, Aug 27

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.

Comment 22 by, Aug 27

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

Comment 23 by, Aug 27

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.

Comment 24 by, Aug 27

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.

Comment 25 by, Aug 28

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.

Comment 26 by, Aug 28

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.

Comment 27 by, Aug 28

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.

Comment 28 by, Oct 24

 Issue 863757  has been merged into this issue.

Comment 29 by, Oct 26

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.

Comment 30 by, Oct 29


Comment 31 by, Oct 29

Labels: Hotlist-CEPartnerEng

Comment 32 by, Oct 29

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.

Comment 33 by, Oct 29

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

Comment 34 by, Nov 5

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

Comment 35 by, Nov 14


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.

Comment 36 by, Nov 14

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.

Comment 37 by, Nov 14

Labels: Restrict-AddIssueComment-EditIssue

Comment 38 by, Jan 2

 Issue 918228  has been merged into this issue.

Sign in to add a comment