~eduvpn/server#155: 
move route/DNS config to OpenVPN client config file

Currently, the OpenVPN server pushes routes, DNS and some other options to the client over the OpenVPN connection.

We could of course also move this to the client config. When the user reconnects (with eduVPN/LC app) they would get the new config, the behavior then becomes identical to WireGuard and the server does not need "apply changes" when changing e.g. routes.

For IP management we'll keep the OpenVPN-way to do that.

Status
REPORTED
Submitter
~fkooman
Assigned to
No-one
Submitted
1 year, 7 months ago
Updated
1 year, 7 months ago
Labels
v3.x

~fkooman added v3.x 1 year, 7 months ago

~fkooman 1 year, 7 months ago

The ultimate goals:

  1. Allow client to choose whether or not to route all traffic over VPN ("default gateway");
  2. Allow client to choose whether or not to block local traffic.

~fkooman 1 year, 7 months ago

The main complication seems to be figuring out the @GW4@ and @GW6@ addresses...

~fkooman 1 year, 7 months ago*

  • Windows
    • eduVPN works great
  • macOS
    • Viscosity works great
    • eduVPN app seems to always want to be default gateway? NOTE: need better testing before I start accusing!
      • DNS works
  • Linux
    • NetworkManager does not pick up DNS from config file, suspect neither routes
  • iOS
    • We suspect same as macOS
  • Android
    • Not tested, but uses OpenVPN, so probably works

Linux NM issue

~fkooman 1 year, 7 months ago*

When you do not explicitly push anything to the client, there is still a bunch of stuff pushed:

2023-09-12 17:23:06 PUSH: Received control message: 'PUSH_REPLY,
explicit-exit-notify 1,
tun-ipv6,
route-gateway 10.208.28.1,
topology subnet,
ping 10,
ping-restart 60,
ifconfig-ipv6 fda6:ec1f:a582:56bb::8/112 fda6:ec1f:a582:56bb::1,
ifconfig 10.208.28.8 255.255.255.128,
peer-id 0,
cipher AES-256-GCM,
protocol-flags cc-exit tls-ekm dyn-tls-crypt,
tun-mtu 1500
'

~fkooman 1 year, 7 months ago

Having a "complete" client config so we do not have to specify --client anymore, but can use --tls-client which does not include --pull would be the dream (= exactly like WireGuard).

I am a bit, actually a lot, afraid we'll end up in 'unexplored terrain' where we'll hit various bugs or incompatibilities, and that won't be fun!

So perhaps limiting it to only routes and DNS would be enough, although even that will be risky.