search

eduvpn / eduvpn-common

Code to be shared between eduVPN clients
MIT License
4 stars 3 forks source link

eduVPN wireguard breaks docker networking #57

Closed defnull closed 1 week ago

defnull commented 2 weeks ago

I'm running eduVPN GUI 4.31 and eduvpn-common 2.0.1 on Linux Mint 21.3 (based on Ubuntu 22.04) and as soon as I connect with eduVPN (using a wireguard profile) docker containers can no longer connect to the internet. Building containers or running commands inside containers that require an internet connection will hang, then timeout.

How to reproduce: 1) Connect to eduVPN (via wireguard) 2) Run docker run --rm alpine apk update. It will hang and then time out.

Expected behavior: eduVPN should install its routes in a way that does not break docker networking (or other bridge or tunnel interfaces that may exist on the host and their attached networks).

jwijenbergh commented 2 weeks ago

Thanks for the issue. Do you have "allow LAN" enabled for wireguard in the settings?

defnull commented 2 weeks ago

No, that setting was off and I'm not sure if I can enable it, since I need access to 10.0.0.0/8 networks via VPN. If that button only excludes private networks that are actually attached to local interfaces, then that would be perfect and solve my issue. But if it excludes all private networks defined by rfc 1918/4193 then it would also deny access to internal networks used by my organization.

I can't really check the difference now since our IT already fixed the docker issue by changing the wireguard profile to explicitly exclude the docker default network. If that's the way to go, of if the "allow LAN" button would have helped, then the issue can be closed I guess. Thanks!

jwijenbergh commented 1 week ago

I can't really check the difference now since our IT already fixed the docker issue by changing the wireguard profile to explicitly exclude the docker default network. If that's the way to go, of if the "allow LAN" button would have helped, then the issue can be closed I guess. Thanks!

Thanks for the update. So IT just excluded 172.17. 0.0/16 from the routes? It is indeed annoying that by default the client would break with docker but this is sort of expected. I recently set the LAN block to default due to VPN attacks on untrusted networks like tunnelvision and tunnelcrack. This is sort of like a security/usability tradeoff. I will close this for now, but see how I can document this better

defnull commented 1 week ago

Thanks for the update. So IT just excluded 172.17.0.0/16 from the routes?

Yes exactly.