Wireguard VPN not connecting after reboot on RUTX09

[flebourse]

There may be an issue with wireguard_watchdog in some cases, different from the one cited above.Could you try the following edit, comment out the wg set ${iface} … and add the two ubus commands:

#  wg set ${iface} peer ${public_key} endpoint "${endpoint_host}:${endpoint_port}"
  ubus call network.interface.${iface} down                                                                            
  ubus call network.interface.${iface} up                                                                              

[Arrinik]

Thank you.
Problem is that i’m not in office until next week.
But i will test it next week.
Can we extend the closing time of this topic?

[flebourse]

@Arrinik

Can we extend the closing time of this topic?

No. Open another.

[Arrinik]

Hi @flebourse,

Unfortunately it did not work with the “ubus” commands.
Do you have any other ideas? It really seems to be the watchdog script. When I run the script manually it sometimes takes a second but there is still no handshake. Sometimes it works after a reboot, but it seems to be a matter of luck.

Once it is connected, however, it seems to work stably.

[flebourse]

Could you show the output of the wg command in the failed state ?
Are you sure the name of the wg server is resolved correctly ?
What is the output of logread -f ?

[Arrinik]

Hi @flebourse,

I have probably found the problem. I also had to make a keep_alive setting on the server.
Another problem could be the NTP server access. An incorrect time on the router can prevent a handshake.

Greetings

[flebourse]

@Arrinik

make a keep_alive setting on the server

No, this isn’t a good idea. If the client just disappears (power outage, …) the server will continue to send keepalive probes on the same src-port <==> dst-port pair the NAT tables will stay open at least partially in the network and will prevent a client reconnection later. To recover you’ll have to change the source port on the client… I’ve been bitten by this one a few weeks ago fortunately I was able to diagnose the issue (one of the wg tunnels was still usable so I did tcpdumps on the other servers). Of course the correct solution is to use a random port on the client. A fix may be coming from the Teltonika side.

An incorrect time on the router can prevent a handshake

Good catch if true. But very dangerous behaviour, you can check the time of the client but how to check the time of the server if it is 8000 km away you can’t connect to it…
I’ll take a look at the source code to be sure.