search

Amebis / eduVPN

Windows eduVPN Client
GNU General Public License v3.0
39 stars 17 forks source link

traffic not 'moved' to split tunnel VPN #245

Open jwijenbergh opened 3 weeks ago

jwijenbergh commented 3 weeks ago

from irc:

17:28 < rudi_s> On Windows 10 with a split tunnel it looks like an established connection is not tunneled through wireguard when its active while wireguard is enabled. 
                Is this expected behavior?
18:11 < fkooman> you mean whether or not TCP connections are "moved" to the VPN after activation and automatically reconnected? 
18:12 < fkooman> the description is a big vague :)
18:14 < fkooman> i am not super familiar with the Windows TCP stack, so perhaps it keeps the TCP connection active outside the VPN until manual reconnect of whatever 
                 application you use, if that is possible? i never noticed that with split tunnels (on Windows)
18:14 < fkooman> but perhaps for "long lived" connections this is different?
20:04 < rudi_s> fkooman: Yes. Something like "connection x is established" -> "enable eduvpn" -> "connection should go through eduvpn/wireguard".
20:05 < rudi_s> The issue is at the moment the windows AD which continues to go "around" the eduVPN which is an issue for us because the AD is only accessible through 
                eduVPN. So when users enable eduVPN the Windows AD is still not accessible (for some time).
20:05 < rudi_s> *which includes file shares.
20:06 < rudi_s> (It seems to work fine with the full tunnel.)
rozmansi commented 2 weeks ago

I can't reproduce this issue. Would need better insight into rudi_s's network organization.

When WireGuard tunnel is activated (or OpenVPN is connected, shouldn't be any different) a split tunnel route is added to Windows routing table. I do notice that sometimes this route may get quite high metric. The route metric is dynamic and Windows add some penalty calculated by network speed, packet loss etc. IIRC this is Network Location Awareness service's and/or Link-layer Topology Discovery Mapper I/O Driver's job. It is normal it takes from some to a few ten seconds before routing changes apply. Maybe the route to AD server via VPN tunnel ends up with higher metric than other routes?

Perhaps PC has another static route to AD server which is more specific than the VPN one? Please, do run route print before and when eduVPN connection is established and locate the most specific route that covers AD server IP in both scenarios.