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

---

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.

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 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.

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;