OpenWRT forums RIP, not sure where to post a feature request/bug for the next LEDE / Wireguard release.
Most of our consumer/entry LEDE routers do not have a battery keeping date/time. The current NTP client method in LEDE is prohibitive of correct and reliable wireguard working.
Since Wireguard is highly dependent on correct date/time, please make sure:
The NTP client is redesigned to load at the very beginning of LEDE bootup, before all else.
Blocking init script actions are a complete no-go. Also there is no connectivity guarantee on boot, you do not want to halt init indefinitely in such a case. And adding arbitrary timeouts will lead back to the initial problem, just with a lot of needless complexity on top.
This looks horribly outdated. OpenWrt/LEDE uses busybox ntpd since quite some time and that will try to sync indefinitely, even when faced with DNS resolve issues initially.
That would leave the router wide open in case of NTP outages or delays.
That's a shame, it means wireguard will never work properly with LEDE on consumer routers which do not have a battery for keeping correct time and/or whose internal clock is off? That is most consumer routers. That is unless traffic "leaks" outside the tunnel, which is worse then the above.
Been testing over a week, as soon as router date/time is significantly in the past at LEDE boot, WG tunnel is active but no data goes through, so NTP can not update date/time through the tunnel. Chicken and egg story, who's first, NTP or WG?
If there's a conceptual chicken/egg problem, how do you expect LEDE to solve it? The NTP problem isn't new and affects other things such as DNSSEC or Secure Neighbor Discovery. Without a trusted time source it simply isn't possible to securely bootstrap. The only secure way is to have a proper RTC or some external time source like a GPS dongle or similar.
First off, wireguard requires monotonic time (always goes forward), not correct time. All that matters is that time marches forward. OpenWRT already has a decent mechanism for getting a reasonably decent time in the not-too-distant past at boot.
Secondly, the lack of an RTC is not an OpenWRT issue, nor even restricted to consumer-grade routers. It is very common not to have an RTC of any significance in embedded devices. If you believe that you've got a situation where wireguard can't be brought up in a reasonable amount of time, then that is a protocol issue, not an OS issue.
Even with an RTC, you've got a 50-50 shot as to if it drifts forward or back. Some RTCs I've worked with have had drifts on the order of a minute per day.
Finally, one can easily implement a "safe" startup sequence, whether it be with scripts or the complexity of systemd. There is no chicken and egg problem.
Wireguard works for me. Please describe the exact issue you experience.
This seems to be a major rumor started in another thread. As @jeff notes:
This is not the case in any wg configuration I implement on any OS. Please provide a log. Are you sure the issue isn't that you're sending all traffic down wg, including the initial DNS request for the wg endpoint???
If neither location has Internet, isn't it still possible to sync time with the remote endpoint...it may not be accurate, but it would be synced? If you are experiencing an issue, this should solve it.
Thanks Jeff, now I understand why as long as I moved date/time forward artificially wireguard worked brilliantly, and it failed when I moved date/time to current after that.
"Easily" depends on one's skills&knowledge; I can follow a guide, where can I find one?
That is very interesting, I'd love to understand how syncing time with the remote endpoint without internet works, and how to set it up to happen at boot.
You have me lost as to what this does exactly?
Like so: Screenshot
wg client configured with server IP, not with url/name, so no DNS req needed?
Also, are you sure you're not trying to send the ntp packets down the wg interface
You're going to need to have ntp go over the unencrypted regular old WAN, or you'll have a chicken and egg problem. I think the solution is to use rc.local to wait until you've got correct time synced, and then bring up wireguard. If you're worried about leakage during this time period, route all traffic, except the ntp traffic, to the loopback interface, and then have your wg script alter the routes when it brings up wireguard.
is a hotplug script and I think what it does is once ntp has come up, someone automatically calls this script, and the script checks to see if it got the action "stratum" and if it did it assumes things are synced up, and (re)starts wireguard.
Assuming the device has an ntpd installed, just set that NTP server as the endpoint address. Easy. Both will have the same time...therefore time never goes "backwards."
I can't recommend a tutorial or walk-through, but would suggest that you learn sh/ash/dash scripting. Be careful, as may references rely on "bash-isms" which are not supported in ash. https://wiki.ubuntu.com/DashAsBinSh is a good reference in knowing what to avoid in writing your scripts.
Not knowing your security/obscurity needs, I'm going to make some assumptions:
"Boring" communication between your router and the outside world is "OK"; DHCP and NTP, in particular
Communication from any of your networked clients should only go through the wireguard channel
As jow pointed out above, start-up scripts should never block for any significant length of time. For many OSes, they should never return a "failure" code, or the boot will stop. Knowing how "daemon" processes work and how to use the hotplug feature he suggested, as well as listening to "events" over ubus will be needed as well.
Given those assumptions, I'd propose something like the following:
Implement "encrypted, secure" DNS if that is important to you
On boot
Start with a set of firewall rules that block forwarding and/or disable forwarding in the kernel with the appropriate sysctl(s)
Start your normal system daemons with the existing scripts, but not wireguard
When you have NTP sync, start wireguard
When you have wireguard connectivity established, enable forwarding
NTP is not available in an encrypted form, only an authenitcated form (for a variety of reasons). If you're really that concerned about time, then you should be running your own NTP master with GPS or other approach that does not require Internet connectivity.
Returning to this "issue" as wireguard is really not working out on travel routers, or routers with power off. This due to RTC requirements. I can't believe wireguard is only for 24/7 power on setups. Despite
I need to login to LEDE LUCI, system, sync time with browser every day simply because router is off at night or during the day when not home. Not useful or user friendly.
I'd like to find a way within LEDE to router power off and back on hours later, and not have to deal with RTC manually, nor mess with a GPS dongle or USB RTC or own NTP server setup?
This wireguard RTC issue is not router specific, tried and tested on 5 different routers running LEDE 17.01.4 over the last +2 weeks. Linksys, Netgear, Nexx, gl:inet, D-Link ...
What's wrong with the hotplug script mentioned early on in the thread? You can use the usual pool.ntp.org server set, so you don't need your own ntp server.
Virtually home-class routers don't have an RTC at all, and I know several of my "desktop" machines are old enough that theirs no longer function.
As so many consider Wireguard here to be the best thing since sliced bread, it seems that Wireguard can function reliably without a RTC,
If the supplied scripts aren't meeting your needs, then I suspect that it is something in the way you are configuring Wireguard, either or both on the client or server, or a flaw in the protocol. The Wireguard-specific, developer mailing lists may have come clues. They would also likely be interested if you have found a meaningful use case that the protocol fails to satisfy.
If I were to guess, all your "hard wiring" of things means that the client tries to continue an existing session on the server and fails due to the client clock "going backward" after the reboot. This is not something that any OS can resolve, OpenWRT or otherwise.This would either be a configuration error, or a Wireguard protocol failing.
If you did not succeed with my advice (setting the routers to an arbitrary time and use one as a NTP server), then perhaps it's time to make a bug report with the Wireguard team.
I made a report regarding another issue...it was promptly fixed in the next release.
Given that Wireguard is an experimental protocol that is still under development, not a turn-key user application for non-technical users, I'd take some time to learn the basics of TCP/IP and NTP, as well as the basic workings of Unix-like operating systems, including shell scripting. Another valuable skill would be knowing how to gather log information and debug information. That knowledge and skill set would be assumed when interacting with a development community.
As lleachii pointed out, unless you've got a specific contribution to make to the Wireguard project, sending mail to the mailing list rather than the project lead will likely get a more positive response.
It's a command you can ssh into the router and cut and paste onto the command line. It looks like in the quote you lose a newline, so here it is again.
Or if you know how to edit files, you can just create the directory /etc/hotplug.d/ntp and edit the file 90-wireguard in that directory to have the contents:
Need to try this if the wireguard service supports it.