Just for the records if anyone has problems with wireguard (not starting the interface/no connection) on clean openwrt: Wireguard doesn´t start / connect when kernel entropy is too low. An my device (AR300M) it took some time after system start to get enough entropy to start wireguard. Apparently there is no error message when entropy is too low. Wireguard simply doesn´t work…
cat /proc/sys/kernel/random/entropy_avail
Too low values will prevent wireguard from establishing a connection. To speed up this process I installed the “haveged” package under openwrt. Now wireguard connections are established directly after system boot.
Security-conscious users should carefully evaluate the algorithms used by haveged as its randomness is reported to not be very good. Poor random number generation can lead to breaking of the crypto that depends on it.
See, for example,
@alzhao – Most all-in-one routers take 30-120 seconds to get to the random: crng init done point in the boot cycle. This is a reality of the available sources of high-quality randomness from these devices. For most users, by the time that NTP sync occurs and the system clock is at or ahead of the last time there were server-client connections (required for Wireguard), there is usually sufficient entropy available for “critical” crypto. Depending on the needs of the application, it can start before the pool is full without exhausting it.
So without haveged (or something similar as we don´t have a hardware random generator) the solution is to wait for “random: crng init done”. This delays the start of wireguard connections which might be undesirable in testing environments, especially to test new wireguard setups.
When I set up my device with a new wireguard installation I ran into this problem… and searched for firewall/routing issues until I figured out the entropy thing. When anything works as intended haveged can be disabled.
haveged is good enough for Tails OS to ship with it, regardless of the many concerns with haveged - there’s a huge amount of politics around the rng in general, and all of it upstream where it likely belongs
Fair amount of discussion over on snbforums.com, where there are maintainers for the rMerlin-AsusWRT fork, along with external scripts and entware packages.
I wouldn’t include haveged as a default package in the build, but it’s there in the repo if folks want to try it.
Except that Linus Torvalds is a big fan of WG - and that means much, as most server side VPN operators are on linux (as is much of the cloud in general)
@alzhao - props for including WG on the products here…
I’d also like to see how Openvpn can be optimised for speed. Openvpn support layer 2 bridge but WG only works on layer 3. There are some requirements for layer 2.
Last time I looked - OpenVPN 3.0 discussion has stalled - the initial requirements were set in 2010, and some high level design work was initiated, but last 3.0 project update on their Trac was 6 years ago…
If Linus likes something it usually gets priority and is accelerated in development, so that is what “means much” refers to. On the other hand OpenVPN is based on OpenSSL which is responsible for all the leaks, hacks and other things in the recent years.
New projects such as Wireguard for VPN and LibreSSL for SSL/TLS are quickly replacing the others.
For example Apple has changed to LibreSSL in High Sierra, and Windows 10 also uses LibreSSL as their provider.
Last time I checked, the whole OpenSSL/LibreSSL thing on OS X was a shim into Apple’s SecureTransport API for legacy and FreeBSD userland stuff
One can do MacPorts/HomeBrew and install the real OpenSSL if desired I suppose, and there the ports teams do keep things current.
Getting back to WG - it’s not just Linus that is excited about WG and making it a priority - if one is following OpenWRT, they’re keeping very current on changes on master…
On master, WG performance on GL-AR300M (NAND) is looking good on the ath79 target - which bodes well for the QCA9331/QCA9531 targets once OpenWRT emits a release - I would never suggest running OpenWRT master in a production use-case - but there are more than a couple of folks looking at ath79 as most upstream development is being done there.
Yes, Apple uses their SecureTransport API for their own apps, but for all other 3rd party they have moved to LibreSSL. So when you compile your program it will be linking to LibreSSL as default.
It’s not based on it. It depends how you compile it. It can be compiled with LibreSSL if desired. I am currently running it linked against the mbedTLS SSL library on my 300M and am seeing upto a 20% speed improvement over the default GL-iNET package.
I mean back in time. There was no LibreSSL, BoringSSL and other forks before the 2014, OpenSSL was the way to go. OpenVPN was based on those crappy coding standards, where old code is left and new code piled on top, causing all the issues that happened later.
LibreSSL was made to be a drop in replacement to OpenSSL, so yeah you can link any program to it if you like.
mbedTLS might be better specifically for OpenWRT, but it’s not great on other platforms cos it doesn’t even have ARM extensions and other optimizations that LibreSSL and others have.
This is quite right. Unfortunately there has been no effort to get OpenWRT into a CI/CD build and be able to do automated testing for performance evaluation. These old projects like OpenWRT live inside mailing lists, closed git repos, and bug trackers with no transparency. They are reluctant to change - it’s near impossible to get them into the way things work now.
Now, you may not like the decisions that the developers make, but the information is hardly hidden
Back closer to on topic, mbedTLS works very well in highly constrained, embedded targets. It is functional for larger systems (and I often test C/C++ on an interactive Linux system), but targeted at smaller systems. Whatever common TLS library used, it depends on the underlying OS for random generation.
That’s the client side - server is on 2.4, and that’s what you’ll be seeing for some time to come.
Anyways - I have no issues with OpenVPN - the 2.4 is portable, secure, and well understood by many. Even Chromebooks do OpenVPN as a supported VPN access type.
