search

runfalk / synology-wireguard

WireGuard support for some Synology NAS drives
MIT License
938 stars 131 forks source link

Synology DSM 6.2.2-24922 breaking WireGuard? #10

Closed runfalk closed 4 years ago

runfalk commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Cyberwizzard commented 5 years ago

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 commented 5 years ago

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.

paatchii commented 5 years ago

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 commented 5 years ago

@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?

paatchii commented 5 years ago

@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 commented 5 years ago

@kharveys Try setting your AllowedIPs to 0.0.0.0/0

paatchii commented 5 years ago

@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 commented 5 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

martinorob commented 4 years ago

@seanauff in this way?

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;

sorry for my zero network know how..

seanauff commented 4 years ago

@martinorob that looks correct

trijethero commented 4 years ago

Guys I am stuck on the handshake

Setup wireguard on my DS918+ for a wireguard server

Have the spk installed, and following in wg0.conf:

[Interface]
Address = 10.0.2.1/16

PrivateKey = -key-
ListenPort = 16666

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; sleep 5; ip route add 10.0.2.1/32 dev wg0;
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = -key-
AllowedIPs = 10.0.2.2/32

in the client side (macbook with wireguard client) I have:

[Interface]
PrivateKey =  -key-
Address = 10.0.2.2/32
DNS = 64.6.64.6

[Peer]
PublicKey = -key-
AllowedIPs = 0.0.0.0/0
Endpoint = my.external.ip:51820
PersistentKeepalive = 25

Firewall is port forwarding 51820 to 16666 on my NAS. It says connected but then loops on the handshake timing out every 5 secs.

[NET] Device started
[NET] peer(YRnJ…5qCE) - Sending handshake initiation
[NET] peer(YRnJ…5qCE) - Awaiting keypair
[APP] Tunnel 'NAS1' connection status changed to 'connected'
[APP] Status update notification timeout for tunnel 'NAS1'. Tunnel status is now 'connected'.
[NET] peer(YRnJ…5qCE) - Handshake did not complete after 5 seconds, retrying (try 2)
[NET] peer(YRnJ…5qCE) - Sending handshake initiation

What am I missing?

seanauff commented 4 years ago

@trijethero Try changing this to your server interface address: ip route add 10.0.2.1/32 dev wg0; to ip route add 10.0.2.1/16 dev wg0;

With just the /32 it still doesn't know where to send packets to your peer.

trijethero commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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

trijethero commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

Tried that, unfortunately no change

trijethero commented 4 years ago

Any other suggestions to fix this?

Networkwilliams commented 4 years ago

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 commented 4 years ago

Bump anyone ?

runfalk commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

eisgruen commented 4 years ago

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 commented 4 years ago

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

robbel commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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