wireguard: automatically add routes to AllowedIPs= #14176
Comments
|
Missing |
yuwata
added
network
needs-reporter-feedback ❓
|
Hi, |
|
Please enable debug logging for networkd and provide the log. The debugging log can be generated by using the following drop-in config: |
|
Hi Again, |
Please also show the result of |
|
Hi, Sorry! Alternatively: Note that I've changed AllowedIPs and are now expecting |
|
|
|
Tested in 244 Problem still persists. Manually I do, however find it wierd that this can be intended behaviour for wireguard in systemd. |
|
Hmm? I am confused. So, do you want to say that |
|
This is the behaviour of running wireguard through wg-quick. I would expect this to be the case for wireguard through networkd as well. Im at my way to a location still running wg-quick, ill output you the routes and corresponding config |
|
From the wg-quick manpages:
The configuration is identical to the configuration above (No excplicit handling of routes) So to your question @yuwata . Yes I think the AllowedIPs records should be added to the route table via networkd Thoughts? |
yuwata
added
RFE 🎁
yuwata
changed the title
|
I think adding routes for
People might want to set I'd be inclined to say routing should be configured in |
|
Hi, Edit: I tried setting some custom routes And while It worked for reaching these networks, it also messed up routing to external network |
|
I suggest to leave networkd as it is now.
Routes should be configured in wg0.netdev: wg0.network: |
|
Hi, Consider you are located on the network of 128.50.0.0/16 Somehow, this route disrupts the network connectivity (routing) for that particular network. Another case is if you wish to route all traffic through the wg interface, which is usually done by 0.0.0.0/0. Creating a route such as: Would disrupt routing where the expected behaviour would be that everything goes fine but through the VPN. |
|
Your configuration example shows Regarding routing all traffic via wireguard: If you mostly care about road-warrior setups, going with wg-quick might be simpler. |
|
@flokli Another option is to add an explicit /32 or /128 to the VPN endpoint itself. That can be firewalled so that it can only be used by the superuser. That said, I strongly recommend using |
|
You need a [RoutingPolicyRule] to make your system use the wireguard connection Netdev can stay the same Network This will make response over wireguard if the system was contacted on 10.0.10.20 address. If you want all traffic to go over wireguard connection use this routing rule: Add to netdev file under This will make all packets that are not wireguard packets to go over wireguard interface. (since wireguard packets need to go over real network) I think making all trafic go over wireguard by default is too much but there might be room of adding source based route by default. Otherwise your system will respond in the asymmetrical fashion by default i.e. if someone tries to open a tcp connection over wireguard (SYN) you will send a SYN-ACK over other interface from different IP address which most likely won't work. |
This works perfectly, thank you for posting it. Do you happen to know how to allow traffic to the client LAN? These are my configs now: Routes are created fine and all the traffic goes through the VPN but I cannot get access to the LAN in any way. I've tried excluding private IPs in the AllowedIPs (grabbed them from the Android App) or creating an additional route but with no lock. Any help would be really appreciated! Thank you :) |
|
You just need a route rule that has higher priority for your LAN. Since your VPN prefix is 10.0.0.0 as well you might have some problems if your LAN is 10.0.0.0 as well. It might be mitigated with smarter routing rules but I have not investigated that. I tested it on my end with a signgle 10.0.0.0/8 on LAN and it seems to work. |
|
Thank you for this but still no luck :( sorry for my noob-ness in all of this, my LAN range is 192.168.88.0/24 so I added this to my network config: |
|
I forgot to tell that the new rule and route should be added to another .network file to the wireguard one.
|
|
If it does not work can you see where packets are going with wireshark. Also check if systemd-networkd successfully restarted and added rule and route. ( |
|
So now I have this config wise: When delete the wg0 iface via networkctl and then restart systemd-networkd I VPN comes back up, I get this error which I assume it's fairly safe: Failed to parse RPDB rule family, ignoring: AF_INETpriority=10fwmark=34952/0 ip rule shows this: ip route show table 5000 comes back empty so I didn't get to the wireshark step as the table doesn't get created. |
|
Try rebooting. You have a lot of garbage rules. Systemd-networkd is not very good at cleaning up. |
`AllowedIPs=` only affects "routing inside the network interface itself", as in, which wireguard peer packets with a specific destination address are sent to, and what source addresses are accepted from which peer. To cause packets to be sent via wireguard in first place, a route via that interface needs to be added - either in the `[Routes]` section on the `.network` matching the wireguard interface, or outside of networkd. This is a common cause of misunderstanding, because tools like wg-quick also add routes to the interface. However, those tools are meant as a "extremely simple script for easily bringing up a WireGuard interface, suitable for a few common use cases (from their manpage). Networkd also should support other usecases - like setting AllowedIPs to 0.0.0.0/0 and ::/0 and having a dynamic routing protocol setting more specific routes (or the user manually setting them). Reported-In: systemd#14176
`AllowedIPs=` only affects "routing inside the network interface itself", as in, which wireguard peer packets with a specific destination address are sent to, and what source addresses are accepted from which peer. To cause packets to be sent via wireguard in first place, a route via that interface needs to be added - either in the `[Routes]` section on the `.network` matching the wireguard interface, or outside of networkd. This is a common cause of misunderstanding, because tools like wg-quick also add routes to the interface. However, those tools are meant as a "extremely simple script for easily bringing up a WireGuard interface, suitable for a few common use cases (from their manpage). Networkd also should support other usecases - like setting AllowedIPs to 0.0.0.0/0 and ::/0 and having a dynamic routing protocol setting more specific routes (or the user manually setting them). Reported-In: #14176
|
Apologies if this is wholly unhelpful to the conversation, but I've arrived here from a netplan configuration actually. On one machine, my netplan configuration adds the routes automatically. When I copy and modify that configuration to a second machine and the routes don't get added automatically, it turns out the difference is in underlying backend. The first that adds routes automatically is NetworkManager whereas the second is networkd. |
`AllowedIPs=` only affects "routing inside the network interface itself", as in, which wireguard peer packets with a specific destination address are sent to, and what source addresses are accepted from which peer. To cause packets to be sent via wireguard in first place, a route via that interface needs to be added - either in the `[Routes]` section on the `.network` matching the wireguard interface, or outside of networkd. This is a common cause of misunderstanding, because tools like wg-quick also add routes to the interface. However, those tools are meant as a "extremely simple script for easily bringing up a WireGuard interface, suitable for a few common use cases (from their manpage). Networkd also should support other usecases - like setting AllowedIPs to 0.0.0.0/0 and ::/0 and having a dynamic routing protocol setting more specific routes (or the user manually setting them). Reported-In: systemd/systemd#14176 (cherry picked from commit c6b90e5)
`AllowedIPs=` only affects "routing inside the network interface itself", as in, which wireguard peer packets with a specific destination address are sent to, and what source addresses are accepted from which peer. To cause packets to be sent via wireguard in first place, a route via that interface needs to be added - either in the `[Routes]` section on the `.network` matching the wireguard interface, or outside of networkd. This is a common cause of misunderstanding, because tools like wg-quick also add routes to the interface. However, those tools are meant as a "extremely simple script for easily bringing up a WireGuard interface, suitable for a few common use cases (from their manpage). Networkd also should support other usecases - like setting AllowedIPs to 0.0.0.0/0 and ::/0 and having a dynamic routing protocol setting more specific routes (or the user manually setting them). Reported-In: systemd/systemd#14176 (cherry picked from commit c6b90e5) (cherry picked from commit 14475e0)
|
Is there any update on this? Setting up a wireguard interface with |
|
I think it would be great to have a way to instruct To route all traffic isn't it enough to specify the gateway like this? It seem to work for me as the route is created with metric 0: Is there any downside of doing that instead of the higher priority table? What would be the recommended way to do the routing? |
…fied in AllowedIPs= Closes systemd#14176.
|
Hi all! I've created PR #21553. If possible, could you test the PR? Any comments and suggestions are welcome. Thank you. |
No. You also need a rule to prioritize Wireguard connection over non-wireguard. And that rule must exclude the Wireguard traffic it self. |
…fied in AllowedIPs= Closes systemd#14176.
|
No. You also need a rule to prioritize Wireguard connection over non-wireguard. And that rule must exclude the Wireguard traffic it self.
Only in cases where you /want/ to override the default route. There's valid reasons to just configure an AllowedIPs to a single IP (/128 or /32), or a more specific prefix than a /0.
I'm still convinced things like wg-quick are more suitable for "road-warrior setups" - at least until networkd gains support for network namespaces. The rule stuff is a big hack.
|
…fied in AllowedIPs= Closes systemd#14176.
…fied in AllowedIPs= Closes systemd#14176.
…fied in AllowedIPs= Closes systemd#14176.
|
|
Yes, but I think something like this PR and #14915 would be one way to tunnel traffic via wireguard in such road-warrior setups, no? |
…fied in AllowedIPs= Closes systemd#14176.
I believe that you will need a |
|
If you want to route all traffic over Wireguard you will need a rule anyway because you need to exclude Wireguard traffic itself. (since it goes over normal network) Both wg-quick and NetworkManager do that, they just automate the process. OpenVPN needs exclusion rule too. |
That's not true - see https://www.wireguard.com/netns/#the-new-namespace-solution, which explains exactly that scenario. |
It relies on UDP sockets being created in one namespace and then the Wireguard device being moved to another one. There are several issues with that and simply adding
|
…fied in AllowedIPs= Closes systemd#14176.
…fied in AllowedIPs= Closes systemd#14176.
|
Why has this "feature" been added even though most people here were against it? |
Probably because some people wanted it. I don't have anything against Here is a thread with the issue: #21964 |
No, that's not how any of this works. Wireguard explicitly keeps track of the namespace it was originally created in and creates its udp sockets directly in that specific namespace, not in the namespace in which the interface resides at that moment. This means that there are no race conditions. |
systemd version the issue has been seen with
Used distribution
Expected behaviour you didn't see
Specifically:
10.0.10.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0Unexpected behaviour you saw
Steps to reproduce the problem
The following configuration was used for Wireguard, the same configuration works for wg-quick (routes gets added normally)
Netdev
Network
The text was updated successfully, but these errors were encountered: