My RUTX11 has suffered several power outages due to the cyclonic conditions in the area, and was unable to re-establish some of the wg tunnels after that.
One tunnel is to a dd-wrt router in the US, this one was still working.
The two others are to a dd-wrt and an Openwrt in Europe, both were stubbornly stuck, never able to receive anything.
A shudown + restart of the tunnels dindn’t help, a full network layer restart neither nor a reboot of RUTX …
The still-working tunnel provided a way to reach everything thanks to ssh -J
From the tcpdump outputs:
- the two EU routers were still trying to send keepalive probes to the other end, receiving nothing,
- the RUTX was sending UDP frames to the correct endpoint:port, received nothing.
I was able to recover both tunnels by changing the value of the listen_port in the UI.
Conclusion: for some mysterious reasons the NAT pinhole path was still open at least partially in the network and as the UDP ports are fixed establishing a new one was impossible. Changing the source port was enough to cope with the issue.
- never enable keepalive on the server’s side of the wg tunnel. It is superfluous anyway,
- don’t use fixed ports on the client’s side.
Unfortunately, the UI of the RUTX doesn’t permit that, even if the “Listen port” field is left as is (51820, greyed) the /etc/config/network file will contain an “option listen_port ‘51820’” line.
Setting Listen port to 0 (zero) is rejected by the UI, and the field is mandatory. And if you have more than one tunnel you have to be careful enough to use different values else the configuration will fail miserably.
The UI of dd-wrt allows the use of 0 as Listen port, the bind() call will return a random value.
In Openwrt, the field is optional (greyed “random” string) and a value of 0 is accepted.
For the moment, I have deleted all “option listen_port …” occurences from /etc/config/network.
@teltonika: could you please fix this, either allow a zero value, set the field a optional or both ?