are WG clients expected to automatically handle it when the endpoint is within the AllowedIPs

are WG clients expected to automatically handle it when the endpoint is within the AllowedIPs

[Christoph Anton Mitterer]

(re-posting, now that the list seems to work again)


Hey folks.

In science/education, many organisations (I could find the total list
only in the Android app, but there it seems to be several 1000) use
eduVPN to provide VPN access to their users.
It comes with a client which, AFAIU, either sets up some OpenVPN or WG
VPN.

I've previously used the OpenVPN profile files successfully with
NetworkManager but now wanted to switch to WG, and again I don't wanna
use the eduVPN client, because I think this should be done with the
native tools that integrate nicely into the system (e.g. NM for desktop
environments, ifupdown/systemd-networkd/etc. for servers).

I guess quite a few sites offer two kinds of profiles, "full" (where
the VPN is set up so that all traffic goes via it) and "split" (where
only the subnets of the respective organisations go via the VPN.

For WG and split a provided config looks like:
[Interface]
MTU = 1392
PrivateKey = blafasl
Address = 10.153.154.19/24,2001:4ca0:4fff:2:4::13/96
DNS =
10.156.33.53,129.187.5.1,2001:4ca0::53:1,2001:4ca0::53:2,lmu.de,uni-
muenchen.de,mwn.de

[Peer]
PublicKey = 7Bp04UdAbZDqChLFgm0sJa6YUaIsye0mZ2c0AxKe5RE=
AllowedIPs =
10.0.0.0/8,85.208.24.0/22,129.27.124.136/32,129.187.0.0/16,131.159.0.0/


16,138.244.0.0/15,138.246.0.0/16,141.39.128.0/18,141.39.240.0/20,141.40


.0.0/16,141.84.0.0/16,172.16.0.0/12,192.54.42.0/24,192.55.197.0/24,192.


68.211.0/24,192.68.212.0/24,192.168.0.0/16,193.174.96.0/23,194.94.155.2


24/28,2001:4ca0::/29,2a09:80c0::/29
Endpoint = eduvpn-n14.srv.lrz.de:51820

for full it's effectively the same, except for:
AllowedIPs = 0.0.0.0/0,::/0


Using that config with NM fails, for which I've opened [0] which is
mostly about the "split" setup and for which there's [1] which is
mostly about the full setup.

The reason being, that the endpoint has IPs that are also within the
AllowedIPs subnet and no special care is taken (well for full, it seems
they’re about to handle it [2]), that packets to the endpoint don't go
via the tunnel.


With wg-quick, full works, but split fails, too, I guess because
add_default is only called in the AllowedIPs = 0.0.0.0/0,::/0 case.
https://github.com/WireGuard/wireguard-tools/blob/17c78d31c27a3c311a2ff42a881057753c6ef2a4/src/wg-quick/linux.bash#L169-L170



So the question is now, should clients be expected to automatically
handle the split case (they apparently are for the full case)...
... or are (split) profiles expected to "simply" (well it could be ugly
in practise) provide their AllowedIPs so that it doesn't contain any
endpoints.

The practical problem with the latter would of course be that the
endpoints will typically be within subnets that shall also be
tunnelled.


Thanks,
Chris.


[0] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1737
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1521
[2] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2158

Re: are WG clients expected to automatically handle it when the endpoint is within the AllowedIPs

[Kajetan Staszkiewicz]

[-- Attachment #1.1: Type: text/plain, Size: 1445 bytes --]

On 2025-05-23 00:36, Christoph Anton Mitterer wrote:
> (re-posting, now that the list seems to work again)
> 
> 
> Hey folks.
> 
> In science/education, many organisations (I could find the total list
> only in the Android app, but there it seems to be several 1000) use
> eduVPN to provide VPN access to their users.
> It comes with a client which, AFAIU, either sets up some OpenVPN or WG
> VPN.
> 
> I've previously used the OpenVPN profile files successfully with
> NetworkManager but now wanted to switch to WG, and again I don't wanna
> use the eduVPN client, because I think this should be done with the
> native tools that integrate nicely into the system (e.g. NM for desktop
> environments, ifupdown/systemd-networkd/etc. for servers).
>
> …
> 
> Using that config with NM fails

NetworkManager's Wireguard implemmentation already has a way of
supporting it by using fwmarks. It's just that the fwmark operation is
not automatically turned unless the tunnel is configured with
AllowedIPs=::/0

See my comment and a workaround which always forces the fwmark operation
on
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1157#note_2426757


-- 
| pozdrawiam / regards | Powered by Debian and FreeBSD  |
| Kajetan Staszkiewicz |   www: http://tuxpowered.net   |
|                      | matrix: @vegeta:tuxpowered.net |
`----------------------^--------------------------------'

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: are WG clients expected to automatically handle it when the endpoint is within the AllowedIPs

[Christoph Anton Mitterer]

Hey.


On Thu, 2025-06-05 at 12:27 +0200, Kajetan Staszkiewicz wrote:
> NetworkManager's Wireguard implemmentation already has a way of
> supporting it by using fwmarks. It's just that the fwmark operation
> is
> not automatically turned unless the tunnel is configured with
> AllowedIPs=::/0

AFAIU, even the AllowedIPs=::/0 case was only fixed[0] (in the sense
of: making it work out-of-the-box) recently, right?

But nevertheless, my main point was,... is it expected to be handled
*automatically* by WG clients?

It's clear that one can always make it somehow manually working, like
with the way from your comment or like how I did with adding a specific
route for the endpoint in [1] (though your approach is probably
cleaner).

And at least as of now, neither NM nor wg-quick seem to work out-of-
the-box with a split profile as described before.


> See my comment and a workaround which always forces the fwmark
> operation
> on
> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1157#note_2426757

I would rather not have that imposed on "end-users"... not ruled out
they get it wrong and perhaps even compromise security.


Cheers,
Chris.


[0] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2158
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1737