Connecting to third party VPN makes open TCP connections hang |
||||
Issue descriptionChrome may have sockets open when a VPN connection is established, e.g. localhost ~ # netstat -an | grep ESTABLISHED tcp 0 0 <wifi_ip>:59021 74.125.28.95:443 ESTABLISHED When a third party VPN comes up, the netfilter rules and routing tables are modified such that all traffic with UID 1000 is routed over tun0. This seems to have a side effect of causing traffic on pre-existing sockets to be routed out tun0, but with wlan0's source IP address. These connections then hang until they time out, which causes intermittent problems accessing Google services right after connecting to a VPN. My proposed workaround is to call FlushSocketPoolsWithError(ERR_NETWORK_CHANGED) upon VPN connection or disconnection. But I am not sure how to get ClientSocketPoolManagerImpl registered for a Chrome OS specific event (NetworkConnectionObserver). Any thoughts on the best way to implement this?
,
Mar 15 2016
We see hangs immediately after connecting to Cisco AnyConnect VPN on a Chromebook.
,
Mar 15 2016
If you navigate to chrome://net-internals/#sockets and click "Flush socket pools", does that fix the hang? That calls the FlushSocketPoolsWithError() function mentioned above, so if it works for you, then my proposed solution should fix the same issue.
,
Mar 16 2016
A VPN connecting should be detected as a network change, which on CrOS should flush all idle connections, close all SPDY/QUIC connections, and cancel all DNS resolution and TCP connect operations. Please collect a net-internals log covering a VPN connect: http://dev.chromium.org/for-testers/providing-network-details Also, what does the "ifconfig" section of chrome://system say when a VPN is up? Are there any directions for configuring a VPN on CrOS?
,
Mar 16 2016
> A VPN connecting should be detected as a network change Could you please point me to the code that handles this? I'll add a printf and see if it's executing.
,
Mar 16 2016
Just collect a net-internals log and it will contain events indicating whether the network change was detected.
,
Mar 25 2016
#CBC-RS/TC-watchlist
,
Mar 29 2016
Landed https://android-review.googlesource.com/#/c/210176/ Will test with this for a while to see if the shill regression was causing the problem.
,
May 5 2016
I haven't seen any issues since the patch landed. Marking as Fixed.
,
May 23 2016
Bulk verified |
||||
►
Sign in to add a comment |
||||
Comment 1 by rsleevi@chromium.org
, Mar 13 2016