It is not just DNS, either. I am unable to ping an IP behind the VPN after waking up and reconnecting.

I can confirm that this also affects ARC-based VPNs. The same occurs when connected through OpenVPN for Android.

I notice the same symptoms turning my wifi off and back on (says "reconnecting" while off and "connected" when turned back on, yet my connectivity never comes back until actually disconnecting and reconnecting the VPN explicitly.) Also, possibly when my IP changes (gbus wifi switching carriers) I am disconnected from the VPN but Chrome thinks it's still connected.

Perhaps this is related to https://bugs.chromium.org/p/chromium/issues/detail?id=555147
(It's mentioned in comment #5, but comment #7 says it's a separate issue.) I am using the VPN through an extension provided by my company rather than the regular Chrome OS interface.

I see this same behavior on a personal pixelbook on M68.  (68.0.3440.70 (Official Build) beta (64-bit))

Can reproduce 100% of the time when sleeping and resuming, or when switching a network.

Dumping ip route show table all when it works vs when it doesn't gives this diff:

-default via 10.13.37.6 dev tun0 table 1 metric 10 
-10.13.37.1 via 10.13.37.6 dev tun0 table 1 metric 1

(10.13.37.0/25 is my VPN internal network, so this certainly makes sense with the symptoms seen.)

I'm trying to make sense of the shill code to figure out if it does something different on "up" vs "restart", but I haven't found anything relevant.

I think that this is related to the following commit: https://chromium.googlesource.com/aosp/platform/system/connectivity/shill/+/7d5406946675cb0d626fc1257f030ebcc7a565fd

It changes how the route table is handled for OpenVPN connections, such that if redirect_gateway is not set in the environment variables, then no route is added for that.  Unfortunately, when the up script is run on restart, redirect_gateway is not set, according to the OpenVPN man page:

NOTE: on restart, OpenVPN will not pass the full set of environment variables to the script. Namely, everything related to routing and gateways will not be passed, as nothing needs to be done anyway - all the routing setup is already in place. Additionally, the up-restart script will run with the downgraded UID/GID settings (if configured).

Consequently, redirect_gateway remains false, so no gateway redirect takes place.

Additionally, this commit landed in R66-10452, which is exactly the build reported by the initial reporter.  I can't find any other commits that look relevant (but I'm not a ChromeOS developer, so I could be completely wrong).

Given the use of persist-tun and the fact that routes never change over a restart of the VPN, it seems like it might be as easy as removing "up-restart" from the OpenVPN config file, so the shill helper is only run on initial connection and not restarts.

I'll try to figure out a way to test locally, but I haven't built ChromeOS or any component from source before, so it might be a while...

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.