Note this in the development tree not the stable release tree. No 7.x has not been released as stable yet and probably won't be for a while. The stable 6.x is still based on an ancient 3.X kernel.
Mikrotik users were requesting support of Wireguard since 2018 but Mikrotik didn't do it because Wireguard wasn't v1.0. At that time, wireguard.com listed dozen of OS/distributions you can use with wg.
Fedora 32 has wireguard. So does any rolling release distro. And for distros with older kernels there are loadable modules that retrofit it. Openwrt has had it for quite some time now.
There are lots of stable Linux distros running the stable kernel which is 5.8. it is just distros like RHEL that call themselves stable, but are actually antiquated and honestly just give users a bad experience because most of the software is outdated. Wouldn't expect anything less from IBM.
I was never a fan of RHEL even before they got purchased. They've done some great things lately with Podman, Buildah, Skopeo, etc but never really been an innovator when it comes to desktop Linux. I see Arch and Alpine being the real innovators, and projects like wlroots.
So is Alpine Linux. Almost no enterprise I've worked at lately wants to deal with antiquated software as long as their Kubernetes distro is working well.
They provided a greatly improved package manager and package interface. Fedora and most other distros don't even come close in terms of the amount of high quality modern packages available from the official repos and AUR, but Alpine has also been growing substantially.
And it's somewhat silly to freeze the kernel. The Linux kernel is meticulous about backwards compatibility. Spin up any distribution user space in docker, and watch it work.
Red Hat also customizes the kernel they've standardized on to disable hardware functionality which they do not want to support under SLA; they have two general ways of doing it, disable compilation of the entire module (where possible) or add the specific PCI ID to a filter-out on that module's supported hardware. The methods tend to route through a custom routine in their kernel patches which notify the user the hardware has been seen but will not function/be supported by their kernel.
This goes the other way around a well, they often cherry-pick new code and pull it back into their curated kernels to support the latest hardware offerings of their partners (Dell, HP, Broadcom, etc.) without pulling in possible unstable newer kernel code around it; they have contractors from those hardware companies assisting in the work to backport hardware module features.
I think it's more thanks to the fact that WireGuard recently got merged to upstream Linux, so all you need to do is to update the kernel and enable it in defconfig.
Do you happen to know, if the RB2011 will be stuck on the (dead-end) ar71xx release, or whether somebody is working on porting it to the newer ath79 platform with LTS?
This is the first I've heard of this. I didn't know it could map to a new platform.
I have two and just got them working and haven't updated in maybe a year. I use them as internal switches and only really use vlans + dhcp.
It might be interesting to see if porting is a big deal. I have one annoying weirdness where ports are labeled sfp,1-5,6-10, but the logical mapping is really screwed up switch0:6, switch0:1,2,3,4,5, then switch1:5,4,3,2,1 (reversed)
I've gotten kernel patches (and some other GPL bits and bobs, although with time they got rid of everything other than the kernel) on request for ROS6.
For ROS7, however, support said in June:
That is not yet readily available since v7 is not really complete yet and is during heavy development right now, everything is changing, including the kernel. I will inquire how long it will take to get the files you need and will let you know once I have some information.
This is a good reminder to ping them again about this.
Actually, WireGuard has first class support now on a large number of distros, without the need for any additional compilation: Ubuntu 16.04, 18.04, 20.04, Fedora, Debian, OpenSUSE, Arch, Mandriva, Alpine, Nix, Void, OpenWRT, and others. Check out www.wireguard.com/install/ for the whole list.
Can confirm, way back I wrote a small guide on how to install and configure Wireguard on the ER-X (and other EdgeRouters), and to date this article is still by far the most read one: https://merlinscholz.name/post/wireguard-on-erx/
Unfortunately 3rd party software installs are lost on updates, so you need to be local to the router before upgrading (or have a secondary VPN available).
Development of EdgeOS has really slowed down though, there hasnt been a stable firmware update in 6 months (and that was just a small hotfix).
"It's free!" they say, if you can get it to run
The Geeks say, "Hey, that's half the fun!"
Yeah, but I got a girlfriend, and things to get done
The Linux OS SUCKS
(I'm sorry to say it, but it does.)
I was about to be annoyed by this comment until I saw it in the context of a song about how every operating sucks, which, when framed like that, I can't help but agree with. ;) (although I will say that I've been having a better time w/ arch linux + dwm lately than any OS / setup I've ever used-- but then again I also love raspberry pis, have like 3 of them, and am, in fact, using one to run dnsmasq / wireguard, so... xD)
One of the main selling points of Wireguard is that it runs much leaner than OpenVPN or IPSec tunnels, especially on embedded hardware, so there isn’t much of a workload in the first place.
Crypto used by IPSec (aes, sha) is often accelerated by hardware - and the above mentioned Ubiquiti has hardware for that. Chacha/Poly used by Wireguard are not.
Of course, benchmarks from random strangers are not gospel, and the results aren’t particularly damning. But even then, you’re assuming that you have the luxury of running on a chip that comes with a hardware crypto engine. Good luck trying to get AES encryption/decryption speeds at anywhere near line rate with a Raspberry Pi or a run-of-the-mill router.
Doesn't feel light to setup if you're trying to get a tunnel working between different providers. We had a strange dead peer issue between Fortigate and Mikrotik and could never figure it out as it happened so rarely. All phase 1 and phase 2 settings were identical. I can imagine that happens elsewhere too.
There are also benefits to running your VPN endpoint on your network gateway - otherwise it can be difficult to configure routing tables to allow a user connecting from outside the network to access both internal and Internet IPs from the tunnel endpoint.
Yeah well don't hold your breath :(. Ubiquiti has been a cluster fuck for a while now and are busy redoing and downgrading the UI again for like the 3rd or 4th time in the last few years rather then add desperately needed basic features. They've released new gateway devices with their own new distro based around containerization, then not actually put that to work at all. DNS still a joke. Zero story for key&certificate management/let's encrypt/etc.
Maybe Pera will get hit by a bus and things will get turned around but otherwise it's a sad mess and waste of potential.
78 comments
[ 5.1 ms ] story [ 159 ms ] threadI guess there is some significant demand for it from Mikrotik's customers. I'll probably use it.
Mikrotik thread: https://forum.mikrotik.com/viewtopic.php?t=134093
MikroTik users don't have it in stable RouterOS releases either. This is a development ("beta") release for testing purposes.
This goes the other way around a well, they often cherry-pick new code and pull it back into their curated kernels to support the latest hardware offerings of their partners (Dell, HP, Broadcom, etc.) without pulling in possible unstable newer kernel code around it; they have contractors from those hardware companies assisting in the work to backport hardware module features.
Try loading (or recompiling) kernel modules. It’s a different story there, as they have no issues breaking that between releases.
[1] - https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=7a...
I have two and just got them working and haven't updated in maybe a year. I use them as internal switches and only really use vlans + dhcp.
It might be interesting to see if porting is a big deal. I have one annoying weirdness where ports are labeled sfp,1-5,6-10, but the logical mapping is really screwed up switch0:6, switch0:1,2,3,4,5, then switch1:5,4,3,2,1 (reversed)
For ROS7, however, support said in June:
This is a good reminder to ping them again about this.Fedora and other distros with recent kernels already have it.
I haven't updated/tested in awhile but last I remember I was seeing 800+ mbit/s on my dinky mips ER-X. Pretty amazing and easy to use.
https://github.com/dynamist/ansible-role-wireguard-vyatta
Development of EdgeOS has really slowed down though, there hasnt been a stable firmware update in 6 months (and that was just a small hotfix).
Why would one want that workload on their router when they can offload it to a $35 Pi?
https://genius.com/Three-dead-trolls-in-a-baggie-every-os-su...
He's not too bright, but he's all we got. :)
https://an.undulating.space/post/181227-er_alternate_firmwar...
Of course, benchmarks from random strangers are not gospel, and the results aren’t particularly damning. But even then, you’re assuming that you have the luxury of running on a chip that comes with a hardware crypto engine. Good luck trying to get AES encryption/decryption speeds at anywhere near line rate with a Raspberry Pi or a run-of-the-mill router.
Maybe Pera will get hit by a bus and things will get turned around but otherwise it's a sad mess and waste of potential.
The Marvell switch chip supports IPv6 but for now Mikrotik only implemented support for v4 offload.. :/