Synology DSM 6.2.2-24922 breaking WireGuard?

[runfalk]

Two days ago my NAS restarted and upgraded to 6.2.2-24922 (from 6.2.1-23824-6) by itself. Since then I can no longer connect using WireGuard.

Changelog doesn't seem to list anything obvious (https://www.synology.com/en-global/releaseNote/DS218j#ver_24922). My kernel compile is fresh, but the version is the same Linux Poseidon 3.10.105 #24922 SMP Fri May 10 02:48:35 CST 2019 armv7l GNU/Linux synology_armada38x_ds218j.

Does anyone else experience the same?

[martin-heinrich]

I can confirm the package is working with DSM 6.2.2-24922 on a DSM981+
4.4.59+ #24922 SMP PREEMPT Fri May 10 02:59:42 CST 2019 x86_64 GNU/Linux synology_apollolake_918+

I did not upgrade from 6.21. to 6.2.2 with WireGuard installed. I only installed your package yesterday. I had no problems getting it to work. I build the package and did not use one of the precompiled ones.

Thank you for sharing the package. Nice work :)

[seanauff]

I experienced the same thing. Installed the latest compiled release and worked perfectly. After update, peers can still connect, but no traffic passes. Uninstalling and reinstalling the package did not help.
Linux Diskstation 4.4.59+ #24922 SMP PREEMPT Fri May 10 02:59:42 CST 2019 x86_64 GNU/Linux synology_apollolake_418play

Edit: Tried building the package myself. Installed fine but having the same issue as precompiled install.

[FlohEinstein]

Just tried a recompile with several wireguard snapshots up to 20190601. Didn't help, problem persists. Wireshark shows packets coming and going between the Wireguard endpoints, but somehow, they don't get any further than wg0. Encryption/decryption problem?
Rewrote parts of Docker file, build.sh and other files so the docker image already contains the tool chain and allow changing the snapshot number as an env parameter.
As soon as I find time to brush up on my cli git, you get a pull request with my version.

Oh, and I asked Synology Support on Twitter for clarification on what has been changed

[runfalk]

Cool, thank you for trying to debug the problem! I find it a bit odd that there is no obvious way to trace/debug wireguard. I tried asking in the IRC on freenode when I discovered the problem, but didn't get much help.

Looking forward to your PR.

[Cyberwizzard]

Same issue for me, DSM 6.2.2-24922 and installed 0.0.20190227-2 from the pre-built packages.

Tried connecting using a Windows and Android client and while the connection engages instantly, no traffic seems to flow from the wg0 interface on the server. Pinging from the clients to the server IP shows packets are arriving at the interface.

One observation: the TX channel at the server shows packet errors, perhaps something broke with the encryption/decryption layer?

          RX packets:23 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:11 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1340 (1.3 KiB)  TX bytes:340 (340.0 B)

[Cyberwizzard]

I changed the base version of Wireguard to 0.0.20190601 (latest at the time of writing), rebuilt and re-installed and also made a pull request for it (#16).

Unfortunately this did not help. I now also switched Android clients and Windows clients, but the TX errors remain.

[Kuermel]

It looks like wireguard is no longer setting the return route.
If this is set manually, the connection works.
But I failed to write this in PostUp.

Steps to reproduce:

wg-quick up wg0
ip route add <Server Interface address> dev wg0

or
ip route add 10.0.1.1/16 dev wg0

[seanauff]

It looks like wireguard is no longer setting the return route.
If this is set manually, the connection works.
But I failed to write this in PostUp.

Steps to reproduce:

wg-quick up wg0
ip route add <Server Interface address> dev wg0

or
ip route add 10.0.1.1/16 dev wg0

I was able to add the route manually as you describe and pass traffic successfully. However, I was also unable to add the route automatically via a PostUp rule or in the scheduled task.

[ghost]

So my understanding is this still doesn't pass internet traffic through? I've written out the Galaxy_NAT.{sh/conf} files according to https://galaxysd.github.io/linux/20170804/2017-08-04-iptables-on-Synology-DSM-6. Looks like my client is directly connecting to the server but attempting to ping any website just times out.

[alexandresoro]

It looks like wireguard is no longer setting the return route.
If this is set manually, the connection works.
But I failed to write this in PostUp.
Steps to reproduce:

wg-quick up wg0
ip route add <Server Interface address> dev wg0

or
ip route add 10.0.1.1/16 dev wg0

I was able to add the route manually as you describe and pass traffic successfully. However, I was also unable to add the route automatically via a PostUp rule or in the scheduled task.

Hi,

I also failed to add the route in the PostUp, however it seems that the scheduled task way works.

Simply adding the ip route add <Server Interface address> dev wg0 after the tasks mentioned in the readme does not work, but it looks like adding a sleep in between would do the trick:

wg-quick up wg0
sleep 5
wg-quick down wg0
sleep 5
wg-quick up wg0
sleep 5
ip route add <Server Interface address> dev wg0

I checked the ip route table after a fresh restart and the VPN route is there. Traffic is OK too.

It's still far from a perfect solution, but at least it survives reboots.

[alexandresoro]

I managed to add the route in the PostUp with a sleep as well.

Here is my PostUp:

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; sleep 3; ip route add <Server Interface address> dev wg0;

I did not need to change the PostDown as the route is deleted on wg-quick down.

Without the sleep, it complains about wg0 not being there.

I just tested on a fresh restart and it seems to work. Hope it helps.

[seanauff]

I managed to add the route in the PostUp with a sleep as well.

Here is my PostUp:

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; sleep 3; ip route add <Server Interface address> dev wg0;

I did not need to change the PostDown as the route is deleted on wg-quick down.

Without the sleep, it complains about wg0 not being there.

I just tested on a fresh restart and it seems to work. Hope it helps.

Great work! Just tried this and it works for me!

[runfalk]

This is great news. I hope to test this soon and make a new release with updated instructions.

[Cyberwizzard]

In my case I am also missing the route and the sleep in the PostUp fixed that.

However, I am still getting TX errors but perhaps this is now a configuration issue.

Just to be clear, the is the single server IP for the Wireguard wg0 interface correct? This is not a server IP plus netmask?

[alexandresoro]

Just to be clear, the is the single server IP for the Wireguard wg0 interface correct? This is not a server IP plus netmask?

Are you referring to the <Server Interface Address> placeholder?
If so, in my case it is the VPN subnetwork like 10.0.0.0/24.
Though I am not sure it is necessary to pass the network or if the NAS IP on the VPN interface with a /32 mask would be enough.

Also in my configuration, the NAS has a “server“ role where my devices are connected to my local network through it. I cannot check the configuration where the NAS is connected to a public VPN provider.

By the way, I just noticed that the wg0 in the PostUp of my earlier post could be replaced by the %ialias.

[ghost]

I just can't seem to get it working. I added the ip route manually (I didn't really know which IP I needed to add there so maybe its wrong) and it starts up just fine with the wg-quick up wg0 command and doing wg show shows that some data is transfering but checking my IP it's still my own IP and not the vpn.

[seanauff]

@kharveys

I just can't seem to get it working. I added the ip route manually (I didn't really know which IP I needed to add there so maybe its wrong) and it starts up just fine with the wg-quick up wg0 command and doing wg show shows that some data is transfering but checking my IP it's still my own IP and not the vpn.

The ip route add command needs the CIDR network address of your wireguard interface.

Are you are trying to set up your Synology as the 'server' and have a remote client run all traffic through the VPN link? What does your AllowedIPs section look like in the client config?

[ghost]

@seanauff I'm trying to use my Synology as a client. The allowedIPs I have set to 0.0.0.0/24. When I try the CIDR adress it gives the following error RTNETLINK answers: File exists so that means it's already routed I'm guessing.

[seanauff]

@kharveys Try setting your AllowedIPs to 0.0.0.0/0

[ghost]

@seanauff When I try that I get another error

[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
Error: argument "suppress_prefixlength" is wrong: Failed to parse rule type

[seanauff]

@kharveys If I were you I would open a new issue so this one stays relevant and then post your configs, both for client and server, making sure to redact your keys.

[Cyberwizzard]

Confirmed workaround; the server IP is not added to the routing table anymore.

Adding this fixed it:
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; sleep 5; ip route add 192.168.123.1/32 dev wg0;

Note that ip route add 192.168.123.1/24 also works, but now IPs belonging to no peers also enter the wireguard wg0 interface, I do not know the implications of that (wasted CPU cycles?)
Rationale for only needing /32 is that Wireguard will add a route for each defined peer into wg0 for the IP(s) associated with it.

[martinorob]

Sorry guys,
i have my synology with this ip 192.168.3.240

and this is my wg0.conf

[Interface]
Address = 10.0.1.1/16
PrivateKey = PRIVK
ListenPort = 16666
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ovs_bond0 -j MASQUERADE; sleep 5; ip route add 192.168.3.240/32 dev wg0;
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ovs_bond0 -j MASQUERADE

[Peer]
# macOS client
PublicKey = PUBK
PresharedKey = PRESHK
AllowedIPs = 10.0.1.2/32

and this is my client config

[Interface]
PrivateKey = PRIVK
ListenPort = 16666
Address = 10.0.1.2/32
DNS = 192.168.3.240

[Peer]
PublicKey = PUBK
PresharedKey = PRESK
AllowedIPs = ::/0, 0.0.0.0/0
Endpoint = MYPUBLICIP:16666
PersistentKeepalive = 25

but it doesn't works..

Thanks

[seanauff]

@martinorob The route you need to add is for the Wireguard interface, so in your case 10.0.1.1

[trijethero]

Thanks for the reply

I amended it to /16 but get this response:

Warning: `/etc/wireguard/wg0.conf' is world accessible
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add 10.0.2.1/16 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; sleep 5; ip route add 10.0.2.1/16 dev wg0;
**RTNETLINK answers: Invalid argument**
[#] ip link delete dev wg0

With /32 i get only this:

/etc/wireguard/wg0.conf' is world accessible
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add 10.0.2.1/16 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; sleep 5; ip route add 10.0.2.1/32 dev wg0;

Is it possible that the NAS is blocking it somewhere? NAS firewall is off.

[seanauff]

@trijethero
I looked at my config and it has a 0 at the end of the IP address so actually try changing that line to:
ip route add 10.0.2.0/16 dev wg0;

[rulistaff]

This doesn't work for me :
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ovs_bond0 -j MASQUERADE; sleep 5; ip route add 10.0.1.1/32 dev wg0;

And this generate errors :

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ovs_bond0 -j MASQUERADE; sleep 5; ip route add 10.0.1.1/24 dev wg0;

I have to use full mask like beyond to make it works properly :
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ovs_bond0 -j MASQUERADE; sleep 5; ip route add 10.0.1.0/24 dev wg0;

[trijethero]

Mine still does not work.

See that there are some difference for instance:
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ovs_bond0 -j MASQUERADE; sleep 5; ip route add 10.0.1.0/24 dev wg0;

for wg0 I have i% but tried wg0 as well
for ovs_bond0 I have eth0 but tried ovs_bond0 as well

From ip a i get:

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:11:32:b4:54:99 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.188/24 brd 192.168.178.255 scope global eth0

and

10: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1
    link/none 
    inet 10.0.3.1/16 scope global wg0
       valid_lft forever preferred_lft forever

Do I have to do anything with iptables?

[seanauff]

@trijethero
It looks like your wg0 interface has an IP of 10.0.3.1/16 which is different than what you show in your config earlier. So, the last PostUp command would need to be:
ip route add 10.0.3.0/16 dev wg0;

Also can take a step back and see if packets are making it to your NAS with:
$ sudo tcpdump port 16666
which should show the handshake requests coming in from your clients.

[trijethero]

Thanks seanauff for the help!
I changed the default values to 10.0.3.x to avoid conflict with other services.

I still get the same error when using 10.0.3.0/16

[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; sleep 5; ip route add 10.0.3.0/16 dev wg0;
RTNETLINK answers: Invalid argument
[#] ip link delete dev wg0

Using /24 I do not get the error, but still fails to connect.

using $ sudo tcpdump port 16666 I get:

19:09:21.010889 IP 192.168.178.67.28580 > 192.168.178.188.16666: UDP, length 148
19:09:26.297097 IP 192.168.178.67.28580 > 192.168.178.188.16666: UDP, length 148
19:09:31.476216 IP 192.168.178.67.28580 > 192.168.178.188.16666: UDP, length 148
19:09:36.729335 IP 192.168.178.67.28580 > 192.168.178.188.16666: UDP, length 148
19:09:41.790259 IP 192.168.178.67.28580 > 192.168.178.188.16666: UDP, length 148
19:09:46.871368 IP 192.168.178.67.28580 > 192.168.178.188.16666: UDP, length 148

So it appears the handshake request are coming in; correct ip and outgoing port from the client, but no handshake...

[runfalk]

@trijethero which WireGuard versions do you have (server and client)? Maybe they are by some unlikely chance uncompatible?

[trijethero]

@runfalk, thanks for all the work!

Your version 0.0.20190227-2.spk and latest Mac client 0.0.20191105 (16)/backend version: 0.0.20191013.

DS918+ DSM version 6.2.2-24922 Update 4

I tried it with iOS wireguard client as well, no joy.

Mac client works with commercial Wireguard providers and I have a separate wireguard server on an GL-AR150 mini router, that one works with the macbook client and iOS clients within my network, even when that is completely removed from the network no connection possible, so no interference.

Edit:
As I did a partial upgrade from my previous NAS, did a clean install today to see if anything carried over from previous settings, still not working.

[seanauff]

@trijethero
what if you run the ip route command manually instead of relying on the PostUp rule? I wonder if the sleep time isn't long enough or the interface to come up for some reason.

[trijethero]

Tried that, unfortunately no change

[trijethero]

Any other suggestions to fix this?

[Networkwilliams]

Mine is also failing. I've used tcpdump and can see traffic, for example DNS requests. What is weird is the source IP used. I have wireguard currently installed on a raspberry Pi and the source IP used is the wg0 interface. Wireguard on the synology the source IP appears to be the client

So when i use tcpdump port 53 I can see DNS requests but no reply, i assume because the source IP used is 10.9.0.2/24

My home network is 192.168.0.0/24, my internet router is 192.168.0.1/24, my synology is 192.168.0.200/24. When using wireguard on a raspberry Pi ( 192.168.0.193/24 ) the peer uses IP address 10.9.0.2/24 but the traffic will use source IP 192.168.0.193, so return traffic knows what IP address to use. When using wireguard on the synology the traffic leaves on source IP 10.9.0.2 so doesn't know how to return back

[Networkwilliams]

Bump anyone ?

[runfalk]

I suggest you open a new issue. This one will at most only be seen by those who have posted in this thread.

I don't know how to help you but maybe someone else does.

[MikeeI]

It looks like wireguard is no longer setting the return route.
If this is set manually, the connection works.
But I failed to write this in PostUp.

Steps to reproduce:

wg-quick up wg0
ip route add <Server Interface address> dev wg0

or
ip route add 10.0.1.1/16 dev wg0

This was the solution for my problem

[eisgruen]

i installed the latest wireguar package, wrote the configs like in the readme:

[Interface]
Address = 10.0.1.1/16
PrivateKey = ++++
ListenPort = 16666
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# client1
[Peer]
PublicKey = 7NwP+UYSQUFHCSGGJN0a/QUzjAcWjhEX/u0v6jYUJUY=
AllowedIPs = 10.0.1.2/32

added startup script. startet client and the tunnel was created. i can ping through the tunnel to a device in my local network. and i can see in an tcpdump for eth0 that that device is trying to answer to my client. But traffic is not routed back into the tunnel.

so i tried out, the tips from that thread, but no success. when i try to add the route
ip add route 10.0.1.1/16 dev wg0

i get an error: RTNETLINK answers: Invalid argument

any idea what i have missed?

[runfalk]

Check that the kernel module is actually loaded: lsmod|grep wireguard

[eisgruen]

thanks @runfalk

seems like it is:

wireguard             206067  0
ip6_udp_tunnel          1903  2 vxlan,wireguard
udp_tunnel              2355  2 vxlan,wireguard
ipv6                  336006  99 sit,ip_vs,nf_defrag_ipv6,wireguard,nf_conntrack_ipv6

it's also possible to ping the server address 10.0.1.1 from the synology. but not the clients and ip route doesn't show any routes for the wireguard net:

default via 192.168.67.1 dev eth0  src 192.168.67.10
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 linkdown
192.168.67.0/24 dev eth0  proto kernel  scope link  src 192.168.67.10

[martinorob]

Some problem here! After synology update wireguard doesn't work anymore.
DSM 6.2.3-25426 broke WireGuard.

[robbel]

@martinorob the instructions above still work for me on DSM 6.2.3-25426. I did compile the latest releases myself via the Docker image so not sure if that makes a difference. My Makefile is patched to look as follows:

+WIREGUARD_VERSION ?= 1.0.20200520
+WIREGUARD_TOOLS_VERSION ?= 1.0.20200513

[mrutyunjay-patel]

hi,
My Workaround , Might help someone out there .

1. Synology IP address in 192.168.x.x. series.
2. Use Any other /16 Address Range for WireGuard. ( 192.[169].x.x or 10.0.x.x )
3. Append following to PostUp
   sleep 5 ; ip route add x.x.0.0/16 dev %i . (192.x.0.0/16 or 10.x.0.0/16)

----Failed pair---
SynoNetwork : 192.168.x.x/16 or /24
Wireguard : 192.168.x.x/16 or /24
----working pair---
SynoNetwork : 192.168.x.x/16
Wireguard : 192.169.x.x/16
----working pair---
SynoNetwork : 192.168.x.x/16
Wireguard : 10.0.x.x/16

---

Device : DS218 Play

---

eth0 : inet addr:192.168.123.97
wg0 : inet addr:192.168.114.1
wg1 : inet addr:10.0.1.1
wg2 : inet addr:192.169.114.1

cat /etc/VERSION

majorversion="6"
minorversion="2"
productversion="6.2.3"
buildphase="GM"
buildnumber="25426"
smallfixnumber="0"
builddate="2020/05/12"
buildtime="05:59:17"

wg --version : wireguard-tools v1.0.20200319 - https://git.zx2c4.com/wireguard-tools/

pre-compiled package source : https://github.com/runfalk/synology-wireguard/releases

file : WireGuard-rtd1296-1.0.20200401.spk

Boot up scripts : ( as per github readme ).

1. sleep 60 ; wg-quick up wg0 ; sleep 5 ; wg-quick down wg0 ; sleep 5 ; wg-quick up wg0
2. sleep 60 ; wg-quick up wg1 ; sleep 5 ; wg-quick down wg1 ; sleep 5 ; wg-quick up wg1
3. sleep 60 ; wg-quick up wg2 ; sleep 5 ; wg-quick down wg2 ; sleep 5 ; wg-quick up wg2

---

Non-working config wg0

---

wg0.conf
[Interface]
Address = 192.168.114.1/16
ListenPort = XXXXX
PrivateKey = -------
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; sleep 5; ip route add 192.168.0.0/16 dev %i
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = -------
AllowedIPs = 192.168.114.2/32

[Peer]
PublicKey = -------
AllowedIPs = 192.168.114.3/32

[Peer]
PublicKey = -------
AllowedIPs = 192.168.114.4/32

---

working config wg1

---

[Interface]
Address = 10.0.1.1/16
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE ; sleep 5 ; ip route add 10.0.0.0/16 dev %i
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = XXXXX
PrivateKey = -------

[Peer]
PublicKey = -------
AllowedIps = 10.0.1.2/32

[Peer]
PublicKey = -------
AllowedIps = 10.0.1.3/32

[Peer]
PublicKey = -------
AllowedIps = 10.0.1.4/32

---

working config wg2

---

wg2.conf
[Interface]
Address = 192.169.114.1/16
ListenPort = XXXXX
PrivateKey = -------
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; sleep 5; ip route add 192.169.0.0/16 dev %i
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = -------
AllowedIPs = 192.169.114.2/32

[Peer]
PublicKey = -------
AllowedIPs = 192.169.114.3/32

[Peer]
PublicKey = -------
AllowedIPs = 192.169.114.4/32

---

[eisgruen]

thanks mrutyunjay-patel, this one worked for me.

working config wg1

[Interface]
Address = 10.0.1.1/16
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE ; sleep 5 ; ip route add 10.0.0.0/16 dev %i
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = XXXXX
PrivateKey = -------

[Peer]
PublicKey = -------
AllowedIps = 10.0.1.2/32

[Peer]
PublicKey = -------
AllowedIps = 10.0.1.3/32

[Peer]
PublicKey = -------
AllowedIps = 10.0.1.4/32

[mistersandman]

I debugged this issue for a bit and found something interesting. These are the commands that wg-quick up wg0 issues when I run it with my wg0.conf:

ip link add wg0 type wireguard
wg setconf wg0 /dev/fd/63
ip -4 address add 10.0.0.1/24 dev wg0
ip link set mtu 1420 up dev wg0

so I played around with manually issuing these commands and found that switching the last two commands does not expose the issue, meaning when the second last command is issued only after the last command, the following route is correctly added to the routing table as desired (output from ip route):

10.0.0.0/24 dev wg0  proto kernel  scope link  src 10.0.0.1

Moreover, I monitored the routing table using ip monitor all while running wg-quick up wg0 and this gave me the following output:

[LINK]70: wg0: <POINTOPOINT,NOARP> mtu 1420 qdisc noop state DOWN
    link/none
[ADDR]70: wg0    inet 10.0.0.1/24 scope global wg0
       valid_lft forever preferred_lft forever
[ROUTE]local 10.0.0.1 dev wg0  table local  proto kernel  scope host  src 10.0.0.1
[LINK]70: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN
    link/none
[ROUTE]10.0.0.0/24 dev wg0  proto kernel  scope link  src 10.0.0.1
[ROUTE]broadcast 10.0.0.0 dev wg0  table local  proto kernel  scope link  src 10.0.0.1
[ROUTE]broadcast 10.0.0.255 dev wg0  table local  proto kernel  scope link  src 10.0.0.1
[LINK]70: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420
    link/none
[ROUTE]Deleted 10.0.0.0/24 dev wg0  proto kernel  scope link  src 10.0.0.1

where the first [LINK] log belongs to the ip link add command, the following [ADDR] and [ROUTE] logs belong to the ip -4 address command and finally the remaining [LINK] and [ROUTE] logs except for the last [ROUTE] log belong to the ip link set command. The last [ROUTE] log always appears a bit delayed clearly well after the wg-quick command finished. It deletes the route we're missing and that has previously and correctly been set up by the ip link set command bringing up the wg0 interface!

Finally, manually issuing the four commands shows, that the route deletion only happens, when the last command is issued quickly enough after the second last one. So when waiting 3-5 seconds after the ip -4 address command, before issuing the final ip link set command, the route does not get deleted and stays in the routing table as desired.

In conclusion, it actually seems like wg-quick is setting up all its routing correctly, but somehow something triggers the removal of this one route. I suspect that some running process (likely unrelated to WireGuard) is monitoring the routing tables for [ADDR] events and then queues this (delayed) route deletion. I did not have any luck yet in identifying which process this might be though, so the last part remains just a guess due to lacking hard evidence.

[nApucco]

@mistersandman

I debugged this issue for a bit and found something interesting. These are the commands that wg-quick up wg0 issues when I run it with my wg0.conf:
...

Thank you so much for this hint!
After hours of trying to understand why routing didn't work for me, I finally found your comment and fixed the issue by manually performing and understanding the steps of wq-quick.