Wireguard breaks after reboot

I have successfully configured Debian 9 as wireguard server and OpenWrt device as wireguard client.

Once I reboot OpenWrt device I can see that it reconnects to Debian server but 'wg show' command shows only few bytes send and 0 bytes received.

Only thing that fixes this issue is if I restart wireguard service on server side. Something strange is happening.

I have tried same thing with Linux laptop and on the laptop I can reboot and reconnect to wireguard without problems. Only OpenWrt somehow "gets stuck".

When wireguard vpn is working I can confirm with traceroute that all trafic is going trough vpn. If restart the whole netowork service, after restart everything works ok, also "ifdown wg0" and "ifup wg0" on OpenWrt work as expected.

So only thing that breakd Wireguard is a reboot of OpenWrt device.

Any ideas why and how to fix this issue?


I found about wireguard_watchdog, but it is also not helping :frowning:

running wireguard_watchdog gives this result in last two lines of the scrip:

  • logger -t wireguard_monitor 'wg0 endpoint vpn.server.org:12345 is not responding for 1574596379 seconds, trying to re-resolve hostname'
  • wg set wg0 peer 'ISvxFAKEmPViAfKEYbPM/F/cDONTqBOTHERUFg=' endpoint vpn.server.org:12345

But still nothing works after running is :frowning:

Thats about 50 years (1970).

Sounds like the system time is not yet set correctly when wireguard starts up.

I remember having seen such problems here in the forum already. Please use the forum search to find the relevant postings.


After adding wireguard to crontab and rebooting OpenWrt it fixes the vpn link after few minutes.
Not sure why manually running the script didn't work.

I have rebooted OpenWrt device multiple times and wireguard_watchdog script seams to work now.

So the fix was:

cat << "EOF" >> /etc/crontabs/root
* * * * * /usr/bin/wireguard_watchdog

wg on openwrt is started with "time in the past", as system time not correct (yet). Then wg refuses to run.

wg must be started after correct system time is set (assuming, peer uses correct time). A "feature" of openwrt is, that this startup-sequence is not guaranteed.


Strange thing is happening again... now three times in a row I still get no vpn connection:

root@OpenWrt:/# wg show
interface: wg0
  public key: suPER/1b8NzXcbdiKIKEYV8YuzroCLgDdsXjPjGwg0=
  private key: (hidden)
  listening port: 38458

  allowed ips:,, ::/0
  transfer: 0 B received, 1.16 KiB sent
  persistent keepalive: every 25 seconds

And I have a RTC clock on this board, so time shouldn't be an issue... but I'll look into it.

1 Like

I have rtc on this board, and during the reboot time is slight late, few minutes only, but not 1970.
Currently board has 14:10 while real time is 14:45.

Still if I restart the network wireguard is still not working. Any ideas why?

WireGuard requires monotonic time

1 Like

Can you expand about monotonic time? How can I know ti OpenWrt is currently providing monotonic time for Wireguard or not?

I have left OpenWrt running with non-working wireguard vpn, after some 15 minutes I came back and saw that vpn is now up and working. I don't see anything in OpenWrt logs.

Not knowing what is happening is quite frustrating.

Monotonic, always going forward (not necessarily accurate).

During early boot, OpenWrt generally sets the time to the time stamp of the most recent file in /etc/. Until NTP or the like takes over, your time is in the past and WireGuard may interpret any packets sent “in the past” (relative to others in a peering session) as an attack.


I bypass this problem by running NTP in a "single shot mode" to set correct time, before starting wg. Also, when having RTC, there might be a graceful time adjustment occuring, by default.


You are completely right, OpenWrt clock goes back in time after a reboot and that breaks Wireguard vpn. Now that I have correctly configured RTC to set correct time on my board after a reboot Wireguard work as expected. Thanks!

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.