WIKIABOUT

FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

Most popular tags

rut955 rut240 rut950 rutx11 rms vpn to openvpn wifi not sms trb140 firmware connection - ipsec on rutx12 rutx09 modbus
We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.

RUTX11 WireGuard no handshake if Allowed IPs = 0.0.0.0/0

+1 vote
1,080 views 29 comments
by anonymous

If RUTX “Allowed IPs = 0.0.0.0/0”, then:

No handshake seen at the server side [FAIL]

root@Teltonika-RUTX11:~# traceroute 10.1.0.1 [FAIL]

root@Teltonika-RUTX11:~# traceroute 1.1.1.1 [FAIL]

root@Teltonika-RUTX11:~# traceroute 216.58.215.78 [FAIL]

Note: the same config works fine when using the WireGuard client on Windows PC.

***

If RUTX “Allowed IPs = 10.1.0.1/32”, then:

Handshake is seen at the server side [SUCCESS]

root@Teltonika-RUTX11:~# traceroute 10.1.0.1 [SUCCESS, 1st hop is 10.1.0.1]

root@Teltonika-RUTX11:~# traceroute 1.1.1.1 [SUCCESS, 1st hop is 192.168.2.1]

root@Teltonika-RUTX11:~# traceroute 216.58.215.78 [SUCCESS, 1st hop is 192.168.2.1]

***

Firmware version: RUTX_R_00.07.02.5

by anonymous
(  deleted  )

2 Answers

0 votes
by anonymous
Hello,

Instead of 0.0.0.0/0 for Allowed IPs, could you try with 0.0.0.0/1 plus 128.0.0.0/1 ?

Regards,
by anonymous

Hello,

***

If "Allowed IPs = 0.0.0.0/1":

Handshake done [OK]

traceroute 10.1.0.1 [OK, 1st hop is 10.1.0.1]

traceroute 1.1.1.1 [OK, 1st hop is 10.1.0.1]

traceroute 216.58.215.78 [OK, but 1st hop is 192.168.2.1]

***

If "Allowed IPs = 128.0.0.0/1":

No handshake.

***

If "Allowed IPs = 0.0.0.0/1" + "128.0.0.0/1":

No handshake.

by anonymous
How is your wireguard tunnel built ? The "Endpoint Host" of the peer -> Advanced Settings, is it a fqdn or an IP address ?

What are the values of the DNS servers ? in which range ?

Could you show the logs of a failed handshake ? Use logread, hide sensitive information if needed.
by anonymous

0.0.0.0/0

logread after I switched the wg1 tunnel off->on:

Thu Aug 25 10:15:18 2022 daemon.notice netifd: Interface 'wg1' is setting up now

Thu Aug 25 10:15:18 2022 daemon.notice netifd: wg1 (10366): grep: /tmp/wireguard/default-status: No such file or directory

Thu Aug 25 10:15:18 2022 daemon.notice netifd: Interface 'wg1' is now down

Thu Aug 25 10:15:18 2022 daemon.notice netifd: Interface 'wg1' is setting up now

Thu Aug 25 10:15:18 2022 daemon.notice netifd: Interface 'wg1' is now up

Thu Aug 25 10:15:18 2022 daemon.notice netifd: Network device 'wg1' link is up

Thu Aug 25 10:15:18 2022 user.warn mwan3-hotplug[10379]: hotplug called on wg1 before mwan3 has been set up

Thu Aug 25 10:15:20 2022 daemon.notice netifd: Wireless device 'radio0' set retry=3

Thu Aug 25 10:15:20 2022 daemon.notice netifd: Wireless device 'radio1' set retry=3

Thu Aug 25 10:15:20 2022 user.warn mwan3-hotplug[10799]: hotplug called on wg1 before mwan3 has been set up

Thu Aug 25 10:15:20 2022 user.notice firewall: Reloading firewall due to ifup of wg1 (wg1)

Thu Aug 25 10:15:20 2022 kern.notice Port link state of port LAN 3 changed to DOWN

Thu Aug 25 10:15:22 2022 kern.notice Port link state of port LAN 3 changed to UP

Thu Aug 25 10:15:22 2022 kern.notice Port speed for port 4 changed to 1000 baseT

***

0.0.0.0/1

logread after I switched the wg1 tunnel off->on:

Thu Aug 25 10:16:43 2022 daemon.notice netifd: Interface 'wg1' is setting up now

Thu Aug 25 10:16:43 2022 daemon.notice netifd: wg1 (14117): grep: /tmp/wireguard/default-status: No such file or directory

Thu Aug 25 10:16:43 2022 daemon.notice netifd: Interface 'wg1' is now down

Thu Aug 25 10:16:43 2022 daemon.notice netifd: Interface 'wg1' is setting up now

Thu Aug 25 10:16:44 2022 daemon.notice netifd: Interface 'wg1' is now up

Thu Aug 25 10:16:44 2022 daemon.notice netifd: Network device 'wg1' link is up

Thu Aug 25 10:16:44 2022 user.warn mwan3-hotplug[14132]: hotplug called on wg1 before mwan3 has been set up

Thu Aug 25 10:16:45 2022 kern.notice Port link state of port LAN 3 changed to DOWN

Thu Aug 25 10:16:45 2022 daemon.notice netifd: Wireless device 'radio0' set retry=3

Thu Aug 25 10:16:45 2022 daemon.notice netifd: Wireless device 'radio1' set retry=3

Thu Aug 25 10:16:45 2022 user.warn mwan3-hotplug[14534]: hotplug called on wg1 before mwan3 has been set up

Thu Aug 25 10:16:46 2022 user.notice firewall: Reloading firewall due to ifup of wg1 (wg1)

Thu Aug 25 10:16:48 2022 kern.notice Port link state of port LAN 3 changed to UP

Thu Aug 25 10:16:48 2022 kern.notice Port speed for port 4 changed to 1000 baseT

***

DNS values are 1.1.1.1 and 8.8.8.8, and are setup only in LAN (192.168.9.1/24) and WiFi (192.168.2.2/24, client).

by anonymous

wg config inside RUTX:

by anonymous

Could you do a tcpdump -i any -n -v 'port 51820' and retry with allowed ip = 128.0.0.0/1 ?

by anonymous

tcpdump results for different AllowedIPs

by anonymous

I don't understand what is going on:

  • with 0.0.0.0/0 packets go from 10.1.0.2 to 147.x
  • with 0.0.0.0/1 packets go from 192.168.2.2 to 147.x
  • and with 128.0.0.0/1 the source jumps from 192.168.2.2 to 10.1.0.2

What is the output of:

  • ifconfig 
  • ip -4 route show
  • ip -4 rule show

with the wg tunnel down. Idem with the tunnel up.

by anonymous

AllowedIPs=128.0.0.0/1, tunnel is up, the results:

by anonymous

tunnel is down, the results:

by anonymous

AllowedIPs=0.0.0.0/0, tunnel is up, the results:

by anonymous
Could you redo the tcpdump with allowed ips = 0.0.0.0/0 the initialization phase is missing ?
by anonymous

I did the steps in the below order:

  1. change AllowedIPs
  2. Turn off the tunnel
  3. Start tcpdump
  4. Turn on the tunnel
  5. Stop tcpdump (when I noticed that the time to do it is ok)

The init phase should be registered, or maybe I do not understand it correctly?

***

Thank you very much for your help!

by anonymous
For allowed ips = 0.0.0.0/0 the first packet comes from 10.1.0.2 and there is no apparent reply from the server, for the two others values the source of the first packet is 192.168.2.2 and the servers at 147.x replies.

What is the value of the Allowed IPs field on the server ?
by anonymous

The content of the /etc/wireguard/wg0.conf file at the server side:

[Interface]

Address = 10.1.0.1/24

Address = fd35:910d:5fbb::1/64

PostUp = iptables -A FORWARD  -i wg0 -j ACCEPT

PostUp = iptables -t nat -I POSTROUTING -o ens192 -j MASQUERADE

PostUp = ip6tables -t nat -I POSTROUTING -o ens192 -j MASQUERADE

PreDown = iptables -D FORWARD  -i wg0 -j ACCEPT

PreDown = iptables -t nat -D POSTROUTING -o ens192 -j MASQUERADE

PreDown = ip6tables -t nat -D POSTROUTING -o ens192 -j MASQUERADE

ListenPort = 51820

PrivateKey = 8…..=

[Peer]

PublicKey = l…..=

AllowedIPs = 10.1.0.2/32

***

The working config of the wg Windows client:

[Interface]
PrivateKey = m......=
ListenPort = 51820
Address = 10.1.0.2/32
DNS = 1.1.1.1
MTU = 1420
[Peer]
PublicKey = L....=
AllowedIPs = 0.0.0.0/0
Endpoint = 147.x.x.x8:51820
PersistentKeepalive = 25
 

by anonymous
The AllowedIPs field should be 10.1.0.2/32,192.168.2.0/24,192.168.9.0/24

Do you have masquerading enabled on wirguard->lan and/or lan->wireguard on the RUTX11 ?
by anonymous

Sorry for the late response but I encountered problems with RUTX.

***

“AllowedIps = 10.1.0.2/32,192.168.2.0/24,192.168.9.0/24” at the RUTX makes it unreachable so I needed to do factory reset and backup restore.

***

“AllowedIps = 00.0.0.0/0” at the RUTX, and “AllowedIps = 10.1.0.2/32,192.168.2.0/24,192.168.9.0/24” at server => no handshake.

***

I think “AllowedIps = 00.0.0.0/0” at the RUTX is ok because the exact same config of WireGuard client runs fine on Windows PC.

by anonymous

masquerading settings

by anonymous

> AllowedIps = 10.1.0.2/32,192.168.2.0/24,192.168.9.0/24 is at the server side.

To help diagnose the issue:

  • Set wireguard => lan to Accept / Accept /Accept and remove masquerading
  • edit wg0.conf on the server, comment out the MASQUERADING commands

and retry with 0.0.0.0/0. Try first to ping 10.1.0.1 from the RUTX. Depending on the result execute tcpdump both on the RUTX and the server (same command as before).

by anonymous

server side: AllowedIPs = 10.1.0.2/32,192.168.2.0/24,192.168.9.0/24

server side: wg0.conf -> MASQUERADING commented out

RUTX side: wireguard => lan (Accept / Accept /Accept) and (masquerading = off)

RUTX side: AllowedIPs = 0.0.0.0/0

No handshake and no tcpdump results at the server side.

by anonymous

Add the following route on the RUTX

ip -4 route add 10.1.0.0/24 dev wg1 proto static scope link

after setting up the tunnel and retry the ping. Use tcpdump -i any -n -v 'port 51820 or icmp' to trace the packets.

by anonymous

did the "ip -4 route add 10.1.0.0/24 dev wg1 proto static scope link"

and "root@Teltonika-RUTX11:~# ping 10.1.0.1"

by anonymous
With the tunnel down, what is the output of traceroute 147.x ?
by anonymous
the output is fine:

1  192.168.2.1 (1st router in office)
 2  192.168.80.2 (2nd router in office)
 3  83.__.__.__4
 4  80.__.__.__3
by anonymous
Something is wrong in the routes, I don't see what yet. Set allowed ips to 0.0.0.0/1 + 128.0.0.0/1, start the tunnel and print the result of ip -4 route show.
by anonymous

I think I will gave up on WireGuard because our time is limited. I do not understand why the handshake packets do not leave the RUTX and why it depends on that AllowedIPs value. IMHO the issue is caused by something else in the RUTX but it is not related to its WireGuard. I cannot understand why the same config just works fine on Windows PC. I need to restore server and RUTX wg configurations now.

by anonymous

I've restored server and RUTX wg configurations.

AllowedIPs=10.1.0.1/32, handshake works, ping 10.1.0.1 works, but I need AllowedIPs=0.0.0.0/0 :)

I appreciate your help. We will try to reach Teltonika. I will post info what was wrong if I discover the bug at all.

0 votes
by anonymous

With the changes below, WireGuard works even if AllowedIPs = 0.0.0.0 / 0

by anonymous
Damned those routes don't appear in the ip -4 route show output!
by anonymous
There is still one problem with this fix: "traceroute 147.xx.xx.xx8" 1st hop is 192.168.2.1, but it should go straight to the wg1 also, "traceroute <anything>" should go through the VPN tunnel.