1

This is happening on Linux router.

Any ideas why I've got public IP calling local IP on Wireguard network interface? Does it look right to you? Exactly those packets don't reach another Wireguard endpoint. Other packets work fine.

Please see tcpdump below for 7.X.X.110 > 192.168.250.111

Packet arrives from server to this router in a local network.

It could be some kind of bug in Linux, Wireguard, etc.

  1. Is there any way to replace source IP from 7.X.X.110 > 192.168.250.111 to 192.168.240.111 > 192.168.250.111 ?

  2. Any other way to attempt to fix it or find a work around?

root@dd-2:~# ifconfig oet1
oet1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.1.240.1  P-t-P:10.1.240.1  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP PROMISC  MTU:1460  Metric:1
          RX packets:14283962 errors:12 dropped:204 overruns:0 frame:12
          TX packets:12498036 errors:1 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:10098365440 (9.4 GiB)  TX bytes:4836896224 (4.5 GiB)

root@dd-2:~# ip r
default via 7.X.X.254 dev eth0
10.1.220.1 via 10.1.240.1 dev oet1
10.1.230.1 via 10.1.240.1 dev oet1
10.1.240.0/24 dev oet1 scope link  src 10.1.240.1
10.1.250.1 via 10.1.240.1 dev oet1
7.X.X.0/22 dev eth0 scope link  src 7.X.X.110
127.0.0.0/8 dev lo scope link
192.168.220.0/24 dev oet1 scope link
192.168.230.0/24 dev oet1 scope link
192.168.240.0/24 dev br0 scope link  src 192.168.240.240
192.168.250.0/24 dev oet1 scope link
root@dd-2:~#

root@dd-2:~# sudo tcpdump -i oet1 -n | grep -e "IP 7.X.X.110"
03:31:42.166816 IP 7.X.X.110 > 192.168.250.111: IP 10.233.66.0.33409 > 10.233.100.219.8443: Flags [S], seq 1921032154, win 65495, options [mss 65495,sackOK,TS val 388916867 ecr 0,nop,wscale 7], length 0

Wireguard version v1.0.20191226.

If I missed some details, please let me know, I'll add it.

Thanks

laimison
  • 579
  • 2
  • 9
  • 17
  • What is the output of `iptables-save`? – Tero Kilkanen Sep 01 '22 at 06:14
  • Only `iptables` and `iptables-restore` commands are available. No `iptables-save`. This is DD-WRT router running Linux `armv7l` kernel `4.9.207`. Maybe some `iptables ... -L` output would be fine to take a look? The only work around is shutdown sender server (192.168.240.111) for at least 10 minutes to avoid these occasional weird packets (with public IP on oet1) to be generated. Sometimes multiple restarts are needed. I think after this time ARP (layer 2) fully cleans. A note that this issue exist for 2 years. It has been unsolvable for so long. So I'll give bounty in a two days. – laimison Sep 01 '22 at 08:55
  • I suspect issue is on router (dd-2), not sender (192.168.240.111). Because, I've fully compared two similar senders, they work exactly the same: routes, iptables, tcpdump, etc confirmed that. The issue is simply that router somehow includes public IP in oet1 traffic when issue kicks in occasionally. – laimison Sep 01 '22 at 08:59
  • No need to check, but just in case linking same issue on DD-WRT community https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1270970#1270970 – laimison Sep 01 '22 at 13:26
  • This command can generate wrong packets: `ping -I oet1 -I 7.X.X.110 192.168.250.111`. So WG behaves same. It uses public IP where it shouldn't use it. The work around to this problem is `iptables -t nat -A POSTROUTING -o oet1 -s 7.X.X.110/32 -d here_is_IP_that_you_want_to_use_instead_of_public_IP_7.X.X.110/32 -j SNAT --to 192.168.250.111`. It could be solution for someone. Unfortunately, I can't use NAT. I need unNATed traffic. 99.99%+ times everything works, but occasionally I get this weird issue. Ping command demonstrates how wrongly it behaves. – laimison May 22 '23 at 19:21

0 Answers0