WireGuard support in Mikrotik RouterOS v7.1beta2 | Hacker News Reader

WireGuard support in Mikrotik RouterOS v7.1beta2

forum.mikrotik.com

148 pointspozibrothers74 comments

Open articleView on HN

We have been waiting for years for UDP OpenVPN, but we get WireGaurd before most major distros. That's something

I don't follow, open on does work on UDP.

Mikrotik's OpenVPN implementation is missing UDP support.

Ah, I see. That's bad.

RouterOS 7 finally supports UDP OpenVPN so at least that's something.

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.

Even windows

AFAIK most of these are DKMS, so compilation (although automated and supported by distro) is still necessary.

At least it will eventually propagate to all distros now that it's in the stable kernel!

Fedora and other distros with recent kernels already have it.

Indeed but now the problem is this Version 7 will likely be in beta for many more years to come...

That was actually really fast considering how long wireguard has(n't) been around. We don't even have it in stable Linux distributions yet.

I guess there is some significant demand for it from Mikrotik's customers. I'll probably use it.

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.

Mikrotik thread: https://forum.mikrotik.com/viewtopic.php?t=134093

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.

Indeed. Official packages exist for Centos / RHEL 7 & 8 for those that need it.

Ubuntu 20.04 LTS ships with Wireguard.

And it was backported to 18.04 and 16.04. And the Debian backports kernel. And SUSE enterprise. And... So indeed GP's comment isn't totally accurate.

> We don't even have it in stable Linux distributions yet.

MikroTik users don't have it in stable RouterOS releases either. This is a development ("beta") release for testing purposes.

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.

Redhat did that before they were bought by 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.

Just "not for me". It's for enterprise as the name says.

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.

How did Arch and Alpine innovate ?

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.

Freezing the RH kernel is mostly to keep closed source kernel modules working. Some proprietary software has those, unfortunately.

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.

User space, yes.

Try loading (or recompiling) kernel modules. It’s a different story there, as they have no issues breaking that between releases.

You are simply not the target audience for enterprise Linux distros. But they have their uses, and I am glad that they exist.

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.

The ball's in your court, Ubiquiti

Not ubiquiti's doing but this repo has pre-built kernel modules of wireguard and vyatta integration for I think most of the edgerouter series: https://github.com/WireGuard/wireguard-vyatta-ubnt

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.

We built an Ansible role to install and configure Wireguard on EdgeOS. It works well on EdgeRouter Infinity ER-8-XG and EdgeRouter X.

https://github.com/dynamist/ansible-role-wireguard-vyatta

This repo appears to use Lochnair's old builds, which are unmaintained/deprecated and replaced with the official ones linked to by GP.

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 not.

Why would one want that workload on their router when they can offload it to a $35 Pi?

Because then you don't have to run an additional $35 Pi.

And apply updates to it...

I understand that amateurs love the Pi and other underpowered, junk hardware, but not everybody wants yet another science project in their life.

"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.)

https://genius.com/Three-dead-trolls-in-a-baggie-every-os-su...

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)

IDK if you know, but it seems you're shadow banned. Which I find annoying because I wanted to reply to another post you wrote.

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.

There’s a benchmark done with the EdgeRouter that shows that Wireguard’s throughput exceeds that of hardware accelerated AES + IPSec:

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.

IPsec is pretty light.

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.

Try enabling Dead Peer Detection (DPD).

Both sides had that on from the beginning.

everything's a lot easier if you can do routing on the router

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.

What features are they needing to add?

Has MikroTik ever made any source code available?

who knows, but I run openwrt on my mikrotik rb2011* switches.

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?

It doesn't seem like porting new devices to ath79 is very involved [1]. I would highly encourage you to make a project out of porting RB2011.

[1] - https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=7a...

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)

A cursory Google search says yes. Not as a public repo or anything, but if you ask them, you'll get it. Examples here: https://forum.openwrt.org/t/mikrotik-gpl-source/6750/10

Supposedly its available by request (which is all that is required by GPL). An old-ish copy is here: https://github.com/robimarko/routeros-GPL

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.

OpenWRT has support for WireGuard as well.

As does VyOS.

Anyone have any experience here with getting wireguard running on pfsense?

I don't think *BSD supports wg yet. would love to see this

AFAIU OpenBSD has official support for Wireguard: https://man.openbsd.org/wg

It was added to NetBSD yesterday.

Nice :)

FreeBSD kernel module in review: https://reviews.freebsd.org/D26137 thanks to Netgate (pfSense)

DD-WRT too

its very handy, I like having a gui to set wg up.

> added Layer3 hardware offloading support for CRS309-1G-8S+IN, CRS312-4C+8XG-RM, CRS326-24S+2Q+RM and CRS354-48G-4S+2Q+RM

The Marvell switch chip supports IPv6 but for now Mikrotik only implemented support for v4 offload.. :/

Reply on news.ycombinator.com