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.

Assigned to
10 months ago
10 months ago

~fkooman 10 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 10 months ago

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

~fkooman 10 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 10 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,
topology subnet,
ping 10,
ping-restart 60,
ifconfig-ipv6 fda6:ec1f:a582:56bb::8/112 fda6:ec1f:a582:56bb::1,
peer-id 0,
cipher AES-256-GCM,
protocol-flags cc-exit tls-ekm dyn-tls-crypt,
tun-mtu 1500

~fkooman 10 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.

Register here or Log in to comment, or comment via email.