Bug Report: WireGuard connection fails after reboot on RUT241 firmware 07.20.1

[thox]

Bug Report: WireGuard connection fails after reboot on RUT241 firmware 07.20.1

Summary

WireGuard VPN connection does not establish after device reboot on firmware RUT2M_R_00.07.20.1, despite correct configuration. The same configuration works reliably on firmware RUT2M_R_00.07.16.3.

Device Information

• Device: RUT241

• Problem Firmware: RUT2M_R_00.07.20.1 (Build: 920eedf3cf1, 2025-12-19)

• Working Firmware: RUT2M_R_00.07.16.3

Problem Description

After configuring WireGuard as a VPN client and rebooting the router:

• The WireGuard interface shows as “up” (ifstatus wg0 shows "up": true)

• wg show shows the interface is active with correct keys

• However, no data is received from the peer (transfer: 0 B received, X KiB sent)

• The handshake with the WireGuard server never completes

Workaround: Opening WebUI and clicking “Save & Apply” (without changing anything) makes the connection work immediately.

Steps to Reproduce

1. Fresh install firmware RUT2M_R_00.07.20.1

2. Configure WireGuard client via WebUI (Services > VPN > WireGuard)

3. Save & Apply - connection works

4. Reboot the router

5. After reboot: interface is up, but no handshake occurs

Diagnostic Output

After reboot (not working):

root@RUT241:~# wg show
interface: wg0
  public key: [REDACTED]
  private key: (hidden)
  listening port: 51820

peer: [REDACTED]
  endpoint: x.x.x.x:51820
  allowed ips: 0.0.0.0/0
  transfer: 0 B received, 2.02 KiB sent   <-- No incoming data

After manual “Save & Apply” (working):

root@RUT241:~# wg show
interface: wg0
  public key: [REDACTED]
  private key: (hidden)
  listening port: 51820

peer: [REDACTED]
  endpoint: x.x.x.x:51820
  allowed ips: 0.0.0.0/0
  latest handshake: 5 seconds ago
  transfer: 7.51 KiB received, 10.75 KiB sent   <-- Working

UCI Configuration (verified correct)

network.wg0=interface
network.wg0.listen_port='51820'
network.wg0.proto='wireguard'
network.wg0.private_key='[REDACTED]'
network.wg0.disabled='0'
network.wg0.addresses='10.8.0.x/24'

Expected Behavior

WireGuard should automatically connect after reboot, as it does on firmware 07.16.3.

Actual Behavior

WireGuard interface starts but connection to peer fails until manual WebUI interaction.

Workaround

Use firmware RUT2M_R_00.07.16.3 instead of 07.20.1.

Additional Notes

• All keys are correct (verified with wg pubkey)

• Server configuration is unchanged and works with other devices

• Problem is 100% reproducible on every reboot

• ifdown wg0 && ifup wg0 via SSH does NOT fix the issue

• Only WebUI “Save & Apply” triggers the connection

[Mike]

I cannot replicate this on my RUT241 with firmware 07.20.1, so try the below.

In order for the Wireguard Watchdog to actively monitor and restart interfaces when necessary, you MUST have a keepalive set in your Peer’s settings. 25 seconds being recommended.

Also you need to place a value in the Interface’s Advanced Settings for the ‘Watchdog interval’ with 1 minute being recommended. I know that the helper says that ’if left blank’ it defaults to 1 minute but there has been a report that it DOES require an entry to function (yet to be verified).

Also some suggestions unrelated …..

If your RUT241 is always the tunnel ‘initiator’, then it’s better NOT to have a listening port set on your interface.

Change your ‘Allowed IP’s’ FROM 0.0.0.0/0 TO 0.0.0.0/1 + 128.0.0.0/1 - this still allows all IPv4 traffic through the VPN tunnel but leaves the the 0.0.0.0/0 route intact so it doesn’t mess with other potential network configurations.

I can’t tell from your ‘wg show’ but would recommend using a DDNS host name as your Peer’s endpoint, if not already done. Even if you provider gives you a static public IP, I’ve known situations where it can change if they’ve done a failover of their infrastructure (rare but possible).

[Justinas]

Greetings,

@Mike thank you for the detailed response.

@thox please let me know whether the issues are resolved after applying the configuration changes Mike suggested, or if you need any further assistance.

Best Regards,
Justinas

[thox]

Thank you @Mike for the detailed suggestions!

I’ve applied all recommended changes:

• Removed Listen port (now dynamic)

• Set Watchdog interval to 1

• Changed Allowed IPs to 0.0.0.0/1 + 128.0.0.0/1

• Set Persistent keepalive to 25 seconds

Unfortunately, the issue persists:

After reboot (not working):

root@RUT241:~# wg show
interface: wg0
  public key: jm64....
  private key: (hidden)
  listening port: 58268

peer: Kd/Kzv.....
  preshared key: (hidden)
  endpoint: [secret_ip]:51820
  allowed ips: 0.0.0.0/1, 128.0.0.0/1
  transfer: 0 B received, 4.91 KiB sent
  persistent keepalive: every 25 seconds

After clicking “Save & Apply” (without changing anything):

root@RUT241:~# wg show
interface: wg0
  public key: jm64....
  private key: (hidden)
  listening port: 51897

peer: Kd/Kzv.....
  preshared key: (hidden)
  endpoint: [secret_ip]:51820
  allowed ips: 0.0.0.0/1, 128.0.0.0/1
  latest handshake: (System clock wound backward; connection problems may ensue.)
  transfer: 14.84 KiB received, 18.14 KiB sent
  persistent keepalive: every 25 seconds

The configuration is identical, only the dynamic listen port changes. The handshake only succeeds after manually triggering “Save & Apply”.

Server-side shows the peer is correctly configured and works immediately after the manual save.

This issue does not occur on firmware 07.16.3 with the same configuration.

Screenshots of my current settings:

[vogon]

What is the output of:

ip -4 route show
ip -4 rule show

before and after the “Save&Apply” action ?

[thox]

Good catch! Here’s the difference:

After reboot (not working):

root@RUT241:~# ip -4 route show
0.0.0.0/1 dev wg0 proto static scope link
default dev qmimux0 proto static scope link src 10.54.54.73 metric 3
10.8.0.0/24 dev wg0 proto kernel scope link src 10.8.0.21
10.54.54.73 dev qmimux0 proto static scope link src 10.54.54.73 metric 3
128.0.0.0/1 dev wg0 proto static scope link
192.168.0.0/20 dev br-lan proto kernel scope link src 192.168.0.1

root@RUT241:~# ip -4 rule show
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

After “Save & Apply” (working):

root@RUT241:~# ip -4 route show
0.0.0.0/1 dev wg0 proto static scope link
default dev qmimux0 proto static scope link src 10.54.54.73 metric 3
10.8.0.0/24 dev wg0 proto kernel scope link src 10.8.0.21
10.54.54.73 dev qmimux0 proto static scope link src 10.54.54.73 metric 3
128.0.0.0/1 dev wg0 proto static scope link
192.168.0.0/20 dev br-lan proto kernel scope link src 192.168.0.1
[server_ip] dev qmimux0 scope link metric 3

root@RUT241:~# ip -4 rule show
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

The host route to the WireGuard server is missing after reboot! This explains why the handshake fails – the router doesn’t know to reach the endpoint via the mobile interface.

“Save & Apply” adds this route, which makes the connection work.

[vogon]

What is the output of:

ip -4 route get [server_ip]
ip -4 route show to match [server_ip]

before the “Save&apply” action ?

[thox]

Here’s the output:

After reboot (not working):

root@RUT241:~# ip -4 route get [SERVER_IP]
[SERVER_IP] dev wg0 src 10.8.0.21 uid 0
    cache

root@RUT241:~# ip -4 route show to match [SERVER_IP]
default dev qmimux0 proto static scope link src 10.52.59.175 metric 3
128.0.0.0/1 dev wg0 proto static scope link

After “Save & Apply” (working):

root@RUT241:~# ip -4 route get [SERVER_IP]
[SERVER_IP] dev qmimux0 src 10.52.59.175 uid 0
    cache

root@RUT241:~# ip -4 route show to match [SERVER_IP]
default dev qmimux0 proto static scope link src 10.52.59.175 metric 3
128.0.0.0/1 dev wg0 proto static scope link
[SERVER_IP] dev qmimux0 scope link metric 3

So the traffic to the WireGuard endpoint is being routed through wg0 instead of qmimux0 after reboot. That’s a routing loop – the router tries to reach the WireGuard server through the WireGuard tunnel itself.

The 128.0.0.0/1 route on wg0 is catching the endpoint IP, and there’s no explicit host route to force it through the mobile interface.

After “Save & Apply”, the host route gets added and traffic correctly goes through qmimux0.

It seems like the firmware doesn’t create this host route automatically on boot, but does create it when saving the configuration.

[vogon]

Increase the metric of the wg interface the field is in Services→VPN→Wireguard edit the tunnel and go to advanced settings. Set the value to at least 5 (I use 9).

[Justinas]

Greetings,

@vogon thank you for the input.

@thox did @vogon’s suggestions help resolve the issue, or do you need any further assistance?

Best Regards,
Justinas

[thox]

Hi,

thanks for the update and for continuing to investigate this.

I haven’t had the chance to apply the suggested change yet, but I plan to test this next week and will report back with the results.

Appreciate the support so far.

[thox]

@vogon I tried setting the metric to 1, 5, and 9 – unfortunately none of these values fixed the issue. After reboot, the host route to the WireGuard server endpoint is still missing, and traffic to the endpoint is still being routed through wg0 instead of qmimux0.

The root cause seems clear: the firmware doesn’t create the host route for the WireGuard endpoint on boot, but does create it when “Save & Apply” is triggered.

[Tansu]

As a workaround you could try making a static route to the wg endpoint with a lower metric then wg itself

[vogon]

Then to determine the cause and fix it it will be necessary to trace the execution of the wireguard proto script. @Justinas IMO the ball is now in the court of Teltonika.

[bsys]

Hello

I experienced a similar issue with wireguard on TRB500 on the latest stable fw (TRB500_R_00.07.19.4).

After reboot there is no route to wireguard server endpoint and wg handshake never completes no matter how long you wait. After disable/enable of wireguard instance and hitting apply (without changing any settings) the connection works as expected.

I have identical setup with two RUT240 (with fw. 07.06.19 and 07.04.5) and no such problems there, so IMO this is an issue with the later firmwares

[Justinas]

Greetings,

@thox For troubleshooting purposes, we will require more sensitive information from your end, such as the troubleshoot file, which may contain passwords, public IP addresses, serial numbers, and such. To avoid leaking this information, we have sent you a form to fill out, which you will receive in your e-mail inbox that you have registered your account with in the forums. In the Ticket ID field of the form, please enter the ID of this thread, which is 17278.

Best Regards,
Justinas

[thox]

Hello @Justinas,

thank you for your message.

I have not yet received the form you mentioned in my email inbox (including the spam folder). Could you please resend it?

In the Ticket ID field I will enter 17278 as requested.

[Justinas]

Greetings,

I have resent the form to you. Please let me know if you have received it.

Best Regards,
Justinas

[thox]

Hello,

I received the form and downloaded the troubleshoot.tar.gz file. However, I can’t find an option to upload the file, there’s only a text field for “Ticket description”. Should I copy and paste the contents of a specific file from the bundle, or am I missing something?

[Justinas]

Greetings,

I have sent you an email, you can reply with the necessary information to it.

Best Regards,
Justinas