[SOLVED]Odd behaviour with wireguard client

Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking
Author Message
bofh@rtfm
DD-WRT Novice


Joined: 21 Nov 2020
Posts: 14

PostPosted: Sat Jan 02, 2021 11:05    Post subject: [SOLVED]Odd behaviour with wireguard client Reply with quote
Router/Version: wrt1900acs
DD-WRT Build: 45036

I have configured a wireguard server in a linux box - tunnel IP address 192.168.40.1
I have configured wireguard client on the dd-wr - tunnel IP address 192.168.40.1

Routing is there in the wireguard server:

Quote:

default via 178.62.64.1 dev eth0 onlink
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
10.16.0.0/16 dev eth0 proto kernel scope link src 10.16.0.5
178.62.64.0/18 dev eth0 proto kernel scope link src 178.62.68.196
192.168.1.0/24 via 192.168.40.2 dev wg0
192.168.20.0/24 dev wg0 scope link
192.168.40.0/24 dev wg0 proto kernel scope link src 192.168.40.1


I can ping from the dd-wrt router to the remote server:


Quote:

root@wrt1900acs:~# ping 192.168.40.1
PING 192.168.40.1 (192.168.40.1): 56 data bytes
64 bytes from 192.168.40.1: seq=0 ttl=64 time=136.046 ms
64 bytes from 192.168.40.1: seq=1 ttl=64 time=135.956 ms
^C
--- 192.168.40.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 135.956/136.001/136.046 ms


When I run tcpdump on the server wg0 interface I can see the outgoing traffic:

Quote:

# tcpdump -n -i wg0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
10:58:12.361903 IP 192.168.40.1.56104 > 192.168.1.55.10050: Flags [S], seq 1339179147, win 42780, options [mss 1380,sackOK,TS val 3350206675 ecr 0,nop,wscale 8], length 0
10:58:13.283441 IP 192.168.40.1 > 192.168.1.240: ICMP echo request, id 8647, seq 0, length 64
10:58:13.385947 IP 192.168.40.1.56104 > 192.168.1.55.10050: Flags [S], seq 1339179147, win 42780, options [mss 1380,sackOK,TS val 3350207699 ecr 0,nop,wscale 8], length 0
10:58:13.386150 IP 192.168.40.1.56104 > 192.168.1.55.10050: Flags [S], seq 1339179147, win 42780, options [mss 1380,sackOK,TS val 3350207699 ecr 0,nop,wscale 8], length 0
10:58:13.388973 IP 192.168.40.1.44053 > 192.168.1.2.161: GetRequest(31) .1.3.6.1.2.1.31.1.1.1.18.3
10:58:13.390877 IP 192.168.40.1.40062 > 192.168.1.5.10050: Flags [S], seq 1476655178, win 42780, options [mss 1380,sackOK,TS val 3051129974 ecr 0,nop,wscale 8], length 0
10:58:14.284383 IP 192.168.40.1 > 192.168.1.240: ICMP echo request, id 8647, seq 1, length 64
10:58:14.409948 IP 192.168.40.1.40062 > 192.168.1.5.10050: Flags [S], seq 1476655178, win 42780, options [mss 1380,sackOK,TS val 3051130993 ecr 0,nop,wscale 8], length 0
10:58:14.410154 IP 192.168.40.1.40062 > 192.168.1.5.10050: Flags [S], seq 1476655178, win 42780, options [mss 1380,sackOK,TS val 3051130993 ecr 0,nop,wscale 8], length 0
10:58:14.413112 IP 192.168.40.1.39952 > 192.168.1.55.161: GetRequest(30) .1.3.6.1.2.1.2.2.1.10.3
10:58:15.285313 IP 192.168.40.1 > 192.168.1.240: ICMP echo request, id 8647, seq 2, length 64
10:58:16.290245 IP 192.168.40.1 > 192.168.1.5: ICMP echo request, id 8652, seq 0, length 64
10:58:16.290562 IP 192.168.40.1 > 192.168.1.7: ICMP echo request, id 8652, seq 1, length 64


However I cannot see it when I run tcpdump on the dd-wrt router:

Quote:

root@wrt1900acs:~# tcpdump -n -i oet1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on oet1, link-type RAW (Raw IP), capture size 262144 bytes



When I try to ping from the internal network the wireguard server 192.168.40.1 I see the outgoing traffic:

Quote:

root@wrt1900acs:~# tcpdump -n -i oet1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on oet1, link-type RAW (Raw IP), capture size 262144 bytes
15:00:29.110977 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 350, seq 1, length 64
15:00:30.112782 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 350, seq 2, length 64
15:00:31.115003 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 350, seq 3, length 64
15:00:32.115799 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 350, seq 4, length 64
15:00:33.116878 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 350, seq 5, length 64
15:00:34.117169 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 350, seq 6, length 64
15:00:35.118630 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 350, seq 7, length 64
15:00:36.119689 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 350, seq 8, length 64


But I dont see it in the wg server incoming log:

Quote:

# tcpdump -n -i wg0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
11:01:13.390894 IP 192.168.40.1 > 192.168.1.240: ICMP echo request, id 9320, seq 0, length 64
11:01:14.391987 IP 192.168.40.1 > 192.168.1.240: ICMP echo request, id 9320, seq 1, length 64
11:01:15.393110 IP 192.168.40.1 > 192.168.1.240: ICMP echo request, id 9320, seq 2, length 64
11:01:16.398400 IP 192.168.40.1 > 192.168.1.5: ICMP echo request, id 9322, seq 0, length 64
11:01:16.398718 IP 192.168.40.1 > 192.168.1.7: ICMP echo request, id 9322, seq 1, length 64
11:01:16.742954 IP 192.168.40.1.42639 > 192.168.1.5.161: GetRequest(2Cool .1.3.6.1.2.1.2.1.0
11:01:17.399128 IP 192.168.40.1 > 192.168.1.5: ICMP echo request, id 9322, seq 2, length 64
11:01:17.399492 IP 192.168.40.1 > 192.168.1.7: ICMP echo request, id 9322, seq 3, length 64
11:01:18.400232 IP 192.168.40.1 > 192.168.1.5: ICMP echo request, id 9322, seq 4, length 64
11:01:18.400567 IP 192.168.40.1 > 192.168.1.7: ICMP echo request, id 9322, seq 5, length 64
11:01:24.607556 IP 192.168.40.1.41270 > 192.168.1.1.22: Flags [S], seq 1628672024, win 42780, options [mss 1380,sackOK,TS val 2337569838 ecr 0,nop,wscale 8], length 0
11:01:24.747298 IP 192.168.40.1.56664 > 192.168.1.55.10050: Flags [S], seq 396649522, win 42780, options [mss 1380,sackOK,TS val 3350399060 ecr 0,nop,wscale 8], length 0
11:01:25.609926 IP 192.168.40.1.41270 > 192.168.1.1.22: Flags [S], seq 1628672024, win 42780, options [mss 1380,sackOK,TS val 2337570840 ecr 0,nop,wscale 8], length 0
11:01:25.610082 IP 192.168.40.1.41270 > 192.168.1.1.22: Flags [S], seq 1628672024, win 42780, options [mss 1380,sackOK,TS val 2337570841 ecr 0,nop,wscale 8], length 0
11:01:25.769906 IP 192.168.40.1.56664 > 192.168.1.55.10050: Flags [S], seq 396649522, win 42780, options [mss 1380,sackOK,TS val 3350400082 ecr 0,nop,wscale 8], length 0
11:01:25.770060 IP 192.168.40.1.56664 > 192.168.1.55.10050: Flags [S], seq 396649522, win 42780, options [mss 1380,sackOK,TS val 3350400083 ecr 0,nop,wscale 8], length 0
11:01:25.772502 IP 192.168.40.1.51322 > 192.168.1.2.161: GetRequest(30) .1.3.6.1.2.1.2.2.1.7.4
11:01:25.774237 IP 192.168.40.1.40622 > 192.168.1.5.10050: Flags [S], seq 2325911717, win 42780, options [mss 1380,sackOK,TS val 3051322357 ecr 0,nop,wscale 8], length 0
11:01:25.912034 IP 192.168.40.1.41280 > 192.168.1.1.22: Flags [S], seq 1313538053, win 42780, options [mss 1380,sackOK,TS val 2337571143 ecr 0,nop,wscale 8], length 0
11:01:26.793930 IP 192.168.40.1.40622 > 192.168.1.5.10050: Flags [S], seq 2325911717, win 42780, options [mss 1380,sackOK,TS val 3051323376 ecr 0,nop,wscale 8], length 0
11:01:26.794098 IP 192.168.40.1.40622 > 192.168.1.5.10050: Flags [S], seq 2325911717, win 42780, options [mss 1380,sackOK,TS val 3051323377 ecr 0,nop,wscale 8], length 0
11:01:26.797045 IP 192.168.40.1.49962 > 192.168.1.55.161: GetRequest(30) .1.3.6.1.2.1.2.2.1.10.1
11:01:26.921935 IP 192.168.40.1.41280 > 192.168.1.1.22: Flags [S], seq 1313538053, win 42780, options [mss 1380,sackOK,TS val 2337572152 ecr 0,nop,wscale 8], length 0
11:01:26.922095 IP 192.168.40.1.41280 > 192.168.1.1.22: Flags [S], seq 1313538053, win 42780, options [mss 1380,sackOK,TS val 2337572153 ecr 0,nop,wscale 8], length 0
11:01:30.407475 IP 192.168.40.1 > 192.168.1.10: ICMP echo request, id 9335, seq 0, length 64
11:01:31.407688 IP 192.168.40.1 > 192.168.1.10: ICMP echo request, id 9335, seq 1, length 64
11:01:32.408791 IP 192.168.40.1 > 192.168.1.10: ICMP echo request, id 9335, seq 2, length 64


If I enable NAT in the dd-wrt GUI I can ping 192.168.40.1 from the local network

Something weird is happening possibly with firewalls or what have you.

Why can I see the outgoing traffic in the 192.168.40.1 tcpdump file but can't see it coming in the dd-wrt 192.168.40.2 tcpdump file?

Any and all help is welcome
Sponsor
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12837
Location: Netherlands

PostPosted: Sat Jan 02, 2021 11:59    Post subject: Reply with quote
I do not know all the subnets of client and server so to get everything going without this knowledge do the following:
Enable NAT on the client
In allowed IP's use: 0.0.0.0/1,128.0.0.0/1
and keep routing allowed IP's enabled

In the WG advanced setup guide there is a paragraph about site-to-site setup where you do not NAT and only allow the servers and clients subnets

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087


Last edited by egc on Sat Jan 02, 2021 13:15; edited 1 time in total
bofh@rtfm
DD-WRT Novice


Joined: 21 Nov 2020
Posts: 14

PostPosted: Sat Jan 02, 2021 12:32    Post subject: Reply with quote
I am afraid I can't do that. The reason is that I also have an openvpn tunnel to a VPN provider

so I have two networks locally behind the dd-wrt router

192.168.1.x whose default gateway is through the internet
192.168.20.x whose default gateway is through the Open VPN tunnel

In the OpenVPN tunnel I have enabled policy based routing (table 10)

The remote linux server - nms - is (amongst other things) the nms server for my home networks

I am running zabbix, ntopng and cacti on that server and it needs to collect information from devices on othe 192.168.1.x network (printers, NAS boxes etc)

I only want to route the 192.168.40.x network via the wireguard tunnel - hence the 192.168.40.0/24 line in the allowed IPs field

It doesn't seem to be an issue with routing but possibly with the firewall

I can see traffic being forwarded from the 192.168.1.x network to 192.168.40.1 from the dd-wrt box wrt1900acs (running tcpdump on the wrt1900acs host on interface oet1)

I can also see traffic towards the 192.168.1.x network from the linux box nms (by running tcpdump on the wg0 interface of the linus box)

BUT on wrt1900acs I cannot see the incoming traffic from nms
and on the linux box I cannot see the incoming traffic from wrt1900acs....
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12837
Location: Netherlands

PostPosted: Sat Jan 02, 2021 13:14    Post subject: Reply with quote
I understand what you want my advice is just a quick test.
If that works you know it is a routing problem (which I think it is)

Besides the WG subnet in allowed IP's you also have to set the subnet of the server in the client and set the clients subnet in the allowed IP's of the server.

As you also route the allowed IP's those subnets will (and should) be routed via the tunnel

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
bofh@rtfm
DD-WRT Novice


Joined: 21 Nov 2020
Posts: 14

PostPosted: Sat Jan 02, 2021 13:25    Post subject: Reply with quote
I tried changing the allowed ips to 0.0.0.0/1,128.0.0.0/1 and lost internet connectivity from the 192.168.1.x subnet so I reverted back ... Sad
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12837
Location: Netherlands

PostPosted: Sat Jan 02, 2021 13:39    Post subject: Reply with quote
It is not to test internet connectivity but if the server is reachable ,internet connectivity depends on the server (which gets all the traffic from the client) is routing that traffic onto the internet and of course you have to enable NAT on the client unless you also set the clients LAN subnet in the allowed IP's of the server.

Have a look at the WG guide page 10:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324787

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
bofh@rtfm
DD-WRT Novice


Joined: 21 Nov 2020
Posts: 14

PostPosted: Sat Jan 02, 2021 15:13    Post subject: Reply with quote
Nope tried again server is not replying

the traffic from a client in 192.168.1.x is routed via oet1:

Code:

19:05:10.485342 IP 192.168.40.2.161 > 192.168.40.1.51401:  GetResponse(34)  .1.3.6.1.2.1.2.2.1.16.2=332248159
19:05:10.546827 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 1000, seq 13, length 64
19:05:10.613466 IP 192.168.40.1.34035 > 192.168.40.2.161:  GetRequest(30)  .1.3.6.1.2.1.2.2.1.10.3
19:05:10.613641 IP 192.168.40.2.161 > 192.168.40.1.34035:  GetResponse(33)  .1.3.6.1.2.1.2.2.1.10.3=7583634
19:05:10.741973 IP 192.168.40.1.51235 > 192.168.40.2.161:  GetRequest(30)  .1.3.6.1.2.1.2.2.1.16.3
19:05:10.742145 IP 192.168.40.2.161 > 192.168.40.1.51235:  GetResponse(34)  .1.3.6.1.2.1.2.2.1.16.3=167173009
19:05:11.586926 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 1000, seq 14, length 64
19:05:12.627256 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 1000, seq 15, length 64
19:05:13.667442 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 1000, seq 16, length 64
19:05:14.706837 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 1000, seq 17, length 64
19:05:15.746915 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 1000, seq 18, length 64
19:05:16.786957 IP 192.168.1.4 > 192.168.40.1: ICMP echo request, id 1000, seq 19, length 64
^C


You can see some SNMP queries from the WG server @192.168.40.1 to wrt1900acs @192.168.40.2 along with the responses

You can also see the ping requst from the internal client 192.168.1.4 to the WG server but no responses

In the picture you see the two tcpdump command outputs on the left from wrt1900acs and on the right from the WG server

It is as if the ICMP packets from wrt1900acs (192.168.40.2) vanish into thin air before they reach the WG server (192.168.40.1)
bofh@rtfm
DD-WRT Novice


Joined: 21 Nov 2020
Posts: 14

PostPosted: Sat Jan 02, 2021 15:33    Post subject: Reply with quote
Got it to work

On the WG server needed to add:

Quote:

AllowedIPs = 192.168.40.2/32,192.168.1.0/24,192.168.20.0/24


Now it works!

Very Happy
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12837
Location: Netherlands

PostPosted: Sat Jan 02, 2021 15:43    Post subject: Reply with quote
Glad you got it working, I tried (but miserably failed) explaining that you needed to set the other sides LAN subnets also in the allowed IP's to get the routing right, anyway glad it is solved.

Have fun and see all the guides for some nice setup examples:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=327397
Smile

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum