MikroTik

Posted: **Sun Jan 19, 2020 4:19 pm**

Wireguard had been widely use by a lot of system. Speed Fast and stable for the vpn tunnel usage.
Cloudflare 1.1.1.1 Warp also using Wireguard as the tunnel for the argo tunnel.

Posted: **Mon Jan 20, 2020 8:45 am**

+1 for WireGuard. This thing is fast! Also, much easier to deploy than OpenVPN.

Posted: **Mon Jan 20, 2020 7:03 pm**

Would be really nice, bringing in some a fresh modern feeling and options...
Unfortunately to take full advantage of it you need a 5.6 kernel

Routeros 7 is on 4.14 as this is a super long LTS kernel. Wireguard just missed the 5.5 which is expected to be the next super long LTS kernel so for routeros we probably have to wait for the next super long LTS which include WG and that would probably be like 5.13-14 in 2 years

And even after that it will probably take a while for mikrotik to adopt the new LTS kernel, they just adopted 4.14 which is already 2 years old so looking back it could be at least 2+2 years before we even see a WG kernel in routeros. If mikrotik don't decide to use the compat WG instead which could run on legacy kernels. I have no idea what the backside is of doing that instead of using a kernel with built in WG support...

Posted: **Tue Jan 21, 2020 3:49 am**

If I understand it correctly, "compat" version of WG are simply backports to older kernels, so there shouldn't be any problem. Call me an optimist, but if WG continues to get popular, and if other things with RouterOS 7 go well, I believe that we can see WG in RouterOS before Christmas (yes, this year, but no, I probably wouldn't bet on it, my optimism has some limits

).

Posted: **Tue Jan 21, 2020 1:31 pm**

The compat version (https://git.zx2c4.com/wireguard-linux-compat/) is the same as what goes into Linux 5.6, it's just the out-of-tree repository.

Posted: **Wed Jan 22, 2020 4:48 pm**

+1 for WireGuard.

Other routers are beginning to deliver...
I don't want to switch supplier.

/joda

Posted: **Wed Jan 22, 2020 7:39 pm**

Hopefully ROS7 will include Wireguard within this year.

Posted: **Wed Jan 22, 2020 8:57 pm**

it would be a dream because now i have a routerboard+raspberry(wireguard) for every single sites of my fullmesh vpn

Posted: **Sat Jan 25, 2020 1:50 pm**

+1 for WireGuard.

Posted: **Sat Jan 25, 2020 3:25 pm**

it would be a dream because now i have a routerboard+raspberry(wireguard) for every single sites of my fullmesh vpn

Yes absolutely !!!
Dream along with me I am on the way to the STARS

Posted: **Sat Jan 25, 2020 9:38 pm**

I'm in.
+1 for WireGuard.

Posted: **Sun Jan 26, 2020 11:48 am**

+1. I also do have additional SBC next to Mikrotik router just for Wireguard VPN server.

Posted: **Sun Jan 26, 2020 3:58 pm**

+1 for Wireguard https://www.wireguard.com/

MikroTik don't ignore us...

Keenetic allready have support WireGuard
https://help.keenetic.com/hc/ru/article ... eGuard-VPN

Posted: **Tue Jan 28, 2020 6:00 pm**

+1. The versatility that comes with wireguard, especially with roaming connections (i.e. swapping back and forth between mobile and wireless) is extremely useful, as well as the increased throughput provided by wireguard. It would be perfect to roll this in with rOS vs. having a separate appliance just to provide this functionality.

Posted: **Wed Jan 29, 2020 10:43 am**

Linus just pulled the net-next branch from David Miller, thus Wireguard is now upstream:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next

Posted: **Wed Jan 29, 2020 6:12 pm**

I really would like to have Wireguard Support in V7.

Posted: **Tue Feb 04, 2020 6:02 pm**

+1 for wireguard, the performance can't be denied.

Posted: **Wed Feb 05, 2020 11:12 am**

+1 for WireGuard.

I believe this is a must going forward for RouterOS 7 its is become a major player in the VPN space

Posted: **Wed Feb 05, 2020 11:26 pm**

Just bought another brand because Mikrotik is missing this feature.
https://www.gl-inet.com/products/gl-mv1000/

Posted: **Fri Feb 07, 2020 2:46 pm**

It would be more than great if we get only one tcp or udp vpn that using certs for encryption, service port could be changed and have windows client (may be third-party).

Posted: **Sat Feb 15, 2020 1:12 am**

just another vote for the fantastic wireguard kit..

Posted: **Sun Feb 16, 2020 3:13 am**

+1 for wireguard .
Please don't repeat the way you did with OpenVPN udp

Posted: **Sun Feb 16, 2020 5:41 am**

+1 for wireguard .
Please don't repeat the way you did with OpenVPN udp

Wireguard is very simple compared to Ovpn, if I'm not mistaken it's only around 4000 lines of code.

Posted: **Sun Feb 16, 2020 12:09 pm**

He was writing OpenVPN UDP support by Mikrotik and not about OpenVPN itself.

A good alternative for now is IKEv2, in the time waiting for Wireguard being implemented by Mikrotik.

Posted: **Sun Feb 16, 2020 8:14 pm**

@msatter I know what he meant I should have been more clear about what I was trying to say, the reason Ovpn went the way it did is because MikroTik wrote their own implementation. With over a million lines of code in the open source implementation you can see how this would be an issue, but with the simplicity of wireguard even if they rewrite there should be no compatability issues.

Posted: **Sun Feb 23, 2020 6:51 pm**

Implementation of something like https://github.com/burghardt/easy-wg-quick would be awesome.

This would allow secure and fast VPN client configuration using a simple QR code to scan.

Posted: **Sun Feb 23, 2020 9:27 pm**

Personally, I think that Wireguard is a bit of a joke, since it's hardcoded to use ChaCha20. So basiclly all systems with AES in hardware becomes useless and has to do it in software. Great work there.

But what about low-end PC's some said? Well... My Celeron N3150 ITX has AES-NI...

So bye bye all hardware offload.

https://www.wireguard.com/protocol/
https://www.reddit.com/r/WireGuard/comm ... use_aesni/

But I have to give it that looks really simple & nice to setup.

Posted: **Mon Feb 24, 2020 12:59 am**

So bye bye all hardware offload.

Wireguard is still faster than AES with offload on the same machine, CPU usage is low as well. The situation I could see this being an issue is with a lot of wireguard sessions, for the typical user needs there is no downside.

Posted: **Mon Feb 24, 2020 5:08 am**

There's good reason to skip AES-NI. It's a speed limit. The lowly atom with AES-NI has the same performance as a 6 core i7 with AES-NI because that little component is a speed limit.

Wireguard is FAST with it's ciphers. It's basically as fast as AES-NI on modest hardware but if you through a serious CPU at it, wireguard rips. A pair of modern i7 CPUs can run 10G over wireguard. There isn't a single AES-NI hardware that can do 1/20 of that consistently.

Wireguard between two raspberry pi is faster than an AES-NI link on everything.

(I've done a lot of testing with wireguard, it's next gen legit and makes AES-NI look like 'MMX'....

Posted: **Mon Feb 24, 2020 10:07 am**

makes AES-NI look like 'MMX'....

Nice comparison, literally lol'd

Posted: **Mon Feb 24, 2020 6:18 pm**

I'm actually more interested in understanding the actually benefits from a server perspective (Mikrotik Router), like the benefits on a ar9344 CPU (which doesn't look like it has AES-NI alike instructions).

That is, *if* we ever get WireGuard in ROS.... LOLO

I'm honestly more geared towards changing my install over time to another brand (and even use OpenWRT) and while I'm doing so, I've started resorting more and more of RasbPI and Linux for all the stuff I want to do and eventually ROS can't (DoH, WireGuard, etc.).

Posted: **Sun Mar 29, 2020 12:33 am**

+1 for WireGuard!

Posted: **Sun Mar 29, 2020 8:22 pm**

Waiting for wireguard.npk or, at least, for an official statement...

Posted: **Tue Mar 31, 2020 12:45 am**

+3 for wireguard

Posted: **Tue Mar 31, 2020 12:49 am**

yes YES YES
this is a must

Posted: **Tue Mar 31, 2020 11:30 am**

Its good to see Wireguard is now "in-tree" on the latest kernel probably won't help here from a technical perspective as I believe RouterOS runs an old Kernel but from a support perspective Wireguard has some stability in the Linux community.

https://arstechnica.com/gadgets/2020/03 ... ux-kernel/

Posted: **Tue Mar 31, 2020 11:33 pm**

Is there official position from Mikrotik about that ?

I think the overwhelming opinion of the community is very positive about Wireguard. Is it something you are exploring ? commiting to ? definitely not on the roadmap ?

Posted: **Fri Apr 03, 2020 1:53 pm**

Its good to see Wireguard is now "in-tree" on the latest kernel probably won't help here from a technical perspective as I believe RouterOS runs an old Kernel but from a support perspective Wireguard has some stability in the Linux community.

https://arstechnica.com/gadgets/2020/03 ... ux-kernel/

RouterOS v7 has v4.14, which is supported by wireguard-linux-compat for what it's worth.

I find it hard to believe it hasn't made it to some (Internal) alpha yet. The kernel module is basically free, the userspace/winbox glue should be trivial to implement.

Posted: **Sat Apr 04, 2020 11:57 am**

+1 for WG support!

Posted: **Thu Apr 09, 2020 2:49 pm**

+1 for WireGuard support

Posted: **Sat Apr 11, 2020 2:30 pm**

+100 for Wireguard support

Posted: **Sat Apr 11, 2020 11:00 pm**

+1
Please support Wireguard

Posted: **Sat Apr 11, 2020 11:55 pm**

In one of the podcasts, Mikrotik said that he would not implement Wireguard Protocol. I can find it if necessary.

Posted: **Wed Apr 15, 2020 1:41 pm**

Rethinking VPN: Tailscale startup packages Wireguard with network security

A whole bunch of tunnels': Mesh networking with per-node permissions and OAuth security
.....
Tailscale's product includes several pieces. First, it's based on peer-to-peer VPNs rather than piping all VPN traffic through a single concentrator. WireGuard security uses public keys. One endpoint can connect to another if it knows the public key and the UDP endpoint (IP address and port) to connect to. Tailscale maintains a database of endpoints on its server, so that when client A needs to talk to client B, it fetches the endpoint details and then makes a direct connection. Tailscale calls this a mesh network.
.....
According to Pennarun, the company was initially more interested in network security than VPNs. An early customer, a bank, wanted to secure a old but critical Windows application, and rather than updating it to use two-factor authentication, he proposed: "Why not move the server into its own little network, so that people can only access that network after they've done two-factor authentication? That was the origin of building this tool. It wasn't intended as a remote access VPN, it was intended as a local access VPN. We did base it on WireGuard because WireGuard was an efficient data plane for their system. It turned out that the core thing we build, this multi-point VPN, was applicable to all sorts of other problems.

Posted: **Sat Apr 18, 2020 11:15 pm**

Please, implement support of WireGuard.

Posted: **Mon Apr 20, 2020 12:36 am**

While I could use WG on a raspberrypi4, it would be so nice to have it in my CCR1009. Current experience with WG is extremely positive, compared to OpenVPN for LAN-LAN-connections.

Posted: **Mon Apr 20, 2020 9:57 am**

Mikrotik have the development smarts to cleanly integrate WireGuard into RouterOS, and now that it has been mainlined I would not be surprised if we see it in the very near future.

Posted: **Mon Apr 20, 2020 2:55 pm**

Mikrotik have the development smarts to cleanly integrate WireGuard into RouterOS, and now that it has been mainlined I would not be surprised if we see it in the very near future.

.
hear hear

Posted: **Fri Apr 24, 2020 2:58 pm**

+1 for Wireguard - keep RouterOS as awesome as it is!

Posted: **Fri Apr 24, 2020 3:14 pm**

nz_monkey is spot on

Posted: **Fri Apr 24, 2020 3:43 pm**

Since it's already reached Version 1.0
+1 for Wireguard

Posted: **Fri Apr 24, 2020 3:57 pm**

nz_monkey is spot on

Is this an subtle acknowledgement that you are working on it?

Posted: **Fri Apr 24, 2020 4:08 pm**

nz_monkey is spot on
Is this an subtle acknowledgement that you are working on it?

Of course it is... We just don't know when. Waiting impatiently

Verstuurd vanaf mijn MI 9 met Tapatalk

Posted: **Fri Apr 24, 2020 4:09 pm**

nz_monkey is spot on
Is this an subtle acknowledgement that you are working on it?

I wouldn't call it "subtle"...
It is logic, after all. It works, is easy to use and (now) was accepted in the kernel tree. But it may take some time - they already have their hands full with RoS 7.

Posted: **Sat Apr 25, 2020 12:24 pm**

Wireguard is a design disaster in every aspect if used on a router. I'm going to name some:

1. You can't just route packets across a wireguard tunnel using the routing table (which is the base of every router), but you have to have some sort of "key" attached to that route. All the dynamic routing thing will just fail. Plus you can't dynamically attach the key to a route at least in the official version of wireguard. (Well, you can provision a tunnel for every device pair but...)

2. No PKI or external AAA support. Since you are going to provision a lot tunnels and there are no "templates" or PKI available, you'll be going to manually add config for **every device**.

3. No support for packet types other than IPv4/IPv6. This means no MPLS support at all.

I would rather go for a better IPSec VTI implementation or ZeroTier integration.

Posted: **Sat Apr 25, 2020 1:11 pm**

Wireguard is a design disaster in every aspect if used on a router. I'm going to name some:

1. You can't just route packets across a wireguard tunnel using the routing table (which is the base of every router), but you have to have some sort of "key" attached to that route. All the dynamic routing thing will just fail. Plus you can't dynamically attach the key to a route at least in the official version of wireguard. (Well, you can provision a tunnel for every device pair but...)

2. No PKI or external AAA support. Since you are going to provision a lot tunnels and there are no "templates" or PKI available, you'll be going to manually add config for **every device**.

3. No support for packet types other than IPv4/IPv6. This means no MPLS support at all.

I would rather go for a better IPSec VTI implementation or ZeroTier integration.

I currently used wireguard with VYOS and they seem to achieve this without a problem, I'm currently creating a wireguard tunnel to another provider (2 actually) and negotiating BGP over those.

https://vyos.readthedocs.io/en/latest/v ... guard.html

This is my workaround until Mikrotik implements this feature.

Posted: **Sat Apr 25, 2020 3:15 pm**

Wireguard is a design disaster in every aspect if used on a router. I'm going to name some:

Yes WireGuard does VPN a little differently -- actually a LOT differently. There is the Old way and now the NEW WireGuard way.

Yes, there is The Classic Solutions of Routing
BUT now there is
The New Namespace Solution .... and Yes it does take a little getting used to and from MY perspective its KISS.

Routing & Network Namespace Integration

Ordinary Containerization

Routing All Your Traffic

The Classic Solutions

The New Namespace Solution

Learning the new way is the future.

RESISTANCE is futile !!! 100% guaranteed.

Posted: **Sat Apr 25, 2020 4:27 pm**

and you can always run a GRE tunnel across wg if you need other protocols, but I don't think that's widely needed.

wg offers a next-gen very capable vpn for road warriors which is probably the main reason for so many requests. Not to say that's the only use, but that's a big one and it suits that role very well.

Posted: **Mon Apr 27, 2020 2:06 pm**

Wireguard is a design disaster in every aspect if used on a router. I'm going to name some:

It's horses for courses. WireGuard is extremely _SIMPLE_, it allows reliable connectivity from devices that roam networks, it is easy to audit, has low overhead and performs well on a wide range of devices.

I would rather go for a better IPSec VTI implementation or ZeroTier integration.

I agree, IPSEC VTI is needed in RouterOS but it has a different use-case to WireGuard. IPSEC VTI is the industry standard and will allow integration with a wide variety of other vendors.

ZeroTier is very cool, but I am not sure how Mikrotik would go with the legal side of integrating it.

Posted: **Tue Apr 28, 2020 6:53 am**

Thanks for the update @normis, it's great to know.

Posted: **Tue Apr 28, 2020 7:42 pm**

IPSEC VTI would also be welcome, but wireguard solves shortcomings in nat traversal and connectivity that no other VPN tech does. wireguard can roam seamlessly as end users switch networks without dropping for example. It doesn't care about the IP addresses packets are coming from and will update the destination to send packets to match the source address the last packet came from. I've tested this using PCC to send packets out different WANs and wireguard doesn't miss a beat.

I don't want to discount IPSEC VTI as that would be a very very good add... but I've lived without that using mikrotik for so long I don't really 'miss' it. On the other hand, mikrotik as the endpoint for road warrior VPNs is a complete fail right now for me as the only remotely reliable option is SSTP over TCP or OpenVPN over TCP. I run separate OpenVPN boxes behind my 'tiks for this. Integrated Wireguard would be immensely valuable for me.

Posted: **Tue Apr 28, 2020 8:24 pm**

+1 for Wireguard

Posted: **Tue Apr 28, 2020 10:00 pm**

+1 for Wireguard

Posted: **Wed Apr 29, 2020 7:40 pm**

+1 Here also. Now i'm running wireguard on SBC behind Mikrotik.

Posted: **Thu Apr 30, 2020 4:57 am**

+1 from me. Wireguard is fantastic for what I am doing

Posted: **Sun May 03, 2020 1:12 pm**

+1 for Wireguard, it's the future of VPN, simplicity and high performance.

Posted: **Mon May 04, 2020 11:20 pm**

+1 absolutely.
i am running a dedicated openvpn/tcp server only for routeros clients (all others are on udp or wireguard already), it's a shame and i want to get rid of it!

Posted: **Mon May 04, 2020 11:48 pm**

I'm 100% sure that this is a must feature for ROS v7. Please, mikrotik, make my dreams come true

Posted: **Wed May 06, 2020 8:10 am**

I second this, it would be a good alternative to something like OpenVPN for client connectivity, especially the multi thread capability which is useful on something like CCR. Other protocol are as important to be implemented, but with Covid-19 pandemic shows that any ways to provide better bandwidth tunnel for workers is better especially many choked on OpenVPN Server. It's not an alternative to IPSEC or IKE but will be a good alternative for OpenVPN (except if OpenVPN is actually multithreaded in the future). Hopefully rOS v7 has a lot of its foundation changes too to allow easier updating of modules for latest version.

Posted: **Fri May 08, 2020 7:31 am**

Hope Mikrotik implemented as possible.

Posted: **Wed May 13, 2020 5:56 pm**

Not complaining here, but I'm beginning to wonder if we've got things all wrong. I, too, wanted the Uber Mikrotik box with everything on it, but Mikrotik hasn't even got OpenVPN with UDP, and I don't see it coming any time soon, even in RouterOS 7. But when I look at it, nearly everything we're asking for is a VPN extension -- RouterOS does fine at routing. That's what it is, that's what it's for. I finally realized I could "path the graps" by putting a $150 box next to it that handles OpenVPN, Wireguard, ZeroTier etc. It's not all in one box, but everything just works.

Posted: **Wed May 13, 2020 5:57 pm**

I also finally realized I can't type today

Posted: **Wed May 13, 2020 8:13 pm**

It depends. It you need huge VPN server for many users, or have some special requirements, then dedicated machine makes sense. But if you need something for only handful of users, then anything external is overkill. Even if it would be the cheapest RasPi-like board, which would be ok price wise, it's another otherwise useless thing you need to manage. Simple VPN server on router is normal and expected feature. And once properly implemented, it should handle even more users on appropriate hardware.

Posted: **Wed May 13, 2020 8:54 pm**

The number of devices is an important part. Space, moving parts, complexity etc.

Wireguard is a very efficient tunnel, you can spin up a very large number of them without taxing a CPU all that much. Wireguard can beat hardware AES-NI in software with it's ChaCha encryption. Wireguard can handle over 1Gbps on an Atom N3000 CPU which is in the same class as the ARM chips in rb4011s. Wireguard scales out too so these many-core mikrotik boxes should handle a substantial amount of traffic, well more than their little AES hardware can today.

If you haven't played with it, you should. I've done some of my own testing running a tunnel to lightsail and I can pull 500Mbps speed tests on that with the little $3 instance's CPU barely in double digit CPU usage.

Proper support in RouterOS is a game changer for me with road warriors.

Posted: **Thu May 14, 2020 2:15 am**

WireGuard is amazing and as you have seen above I support it being added to RouterOS.

But... WireGuard is still a very new technology, and is missing a lot of niceties, as an example it currently has no mechanism to dynamically assign IP addresses to remote clients.

So while the enthusiasm is great, don't let your expectations of WireGuard exceed reality or you will be disappointed.

Posted: **Sun May 17, 2020 11:10 am**

+1 for Wireguard
Implementing this directly on our router would be the most reliable solution for us.

Posted: **Mon May 18, 2020 12:40 am**

I don't think more +1's are necessary, it's being added

Posted: **Mon May 18, 2020 1:25 pm**

I don't think more +1's are necessary, it's being added

But, me too!

+1 for WireGuard.

WireGuard aims to provide a VPN that is both simple and highly effective. ... a codebase of around 4000 lines of pure kernel code,
about 1% of either OpenVPN or IPsec, making security audits easier, and praised by the Linux kernel creator Linus Torvalds
compared to OpenVPN and IPsec as a "work of art".
...
Oregon senator Ron Wyden has recommended to the National Institute of Standards and Technology (NIST) that they evaluate WireGuard
as a replacement for existing technologies like IPsec and OpenVPN.

Source https://en.wikipedia.org/wiki/WireGuard

Posted: **Tue May 19, 2020 1:42 am**

+1 for Wireguard, faster than anything else

Posted: **Tue May 26, 2020 2:12 am**

> Wireguard just missed the 5.5 which is expected to be the next super long LTS kernel

Just want to add, ubuntu has backported it to 5.4, see here: https://git.launchpad.net/~ubuntu-kerne ... 2be3b7ed38

Posted: **Tue May 26, 2020 10:57 am**

+1 .... yes, please

Posted: **Tue May 26, 2020 4:33 pm**

+1 for Wireguard support

Posted: **Tue May 26, 2020 5:20 pm**

+1 for wireguard.

btw. German Telekom is placing wireguard into their end-user routers: https://www.en24.news/2020/05/telekom-t ... uters.html

Posted: **Thu May 28, 2020 12:36 pm**

+1 for Wireguard support

Posted: **Thu May 28, 2020 3:13 pm**

+1 for Wireguard support

Posted: **Thu May 28, 2020 3:46 pm**

+1 for Wireguard support

Posted: **Fri May 29, 2020 3:00 pm**

+1 for WireGuard

Posted: **Tue Jun 02, 2020 1:33 pm**

+1 for wireguard!

Posted: **Wed Jun 03, 2020 6:17 pm**

+10 Guys

I really need wireguard to rebuid VPN links between networks

Posted: **Thu Jun 04, 2020 1:35 pm**

7.0beta7 (2020-Jun-3 16:31):
!) system kernel has been updated to version 5.6.3;

niceeeeeeeee, guess we are on the right path

Posted: **Fri Jun 05, 2020 9:53 pm**

@normis Can we exchange a pizza fundraiser for a WG in upcoming beta(s)?

Posted: **Sun Jun 07, 2020 7:34 am**

I am against WireGuard - no Hardware offload.
I am used to ipsec that works great. If u need WireGuard better install it on a server with powerful cpu.

Posted: **Sun Jun 07, 2020 7:57 am**

@markwien Have you ever used or familiarized yourself with WG? It doesn't use AES and thus cannot use hardware offload. However, this is only one side of the coin: the crypto WG uses is on par or faster than AES with acceleration, since it was designed to utilize features of modern CPUs.

Detailed benchmarks: https://an.undulating.space/post/181227 ... enchmarks/

TL;DR - on budget EdgeRouter Lite (dualcore, 500Mhz MIPS64):

Screen Shot 2020-06-06 at 11.56.00 PM.png

I really don't want to start a flamewar here, because it's not a place for it, but even folks maintaining IPSec subsystem in the Linux kernel subtree agree that WG is vastly superior in most of the scenarios.

Posted: **Sun Jun 07, 2020 2:18 pm**

If u need WireGuard better install it on a server with powerful cpu.

The opposite is true .... @markwien - ignorance is no excuse!

Posted: **Mon Jun 08, 2020 12:28 am**

@markwien
Detailed benchmarks: https://an.undulating.space/post/181227 ... enchmarks/

TL;DR - on budget EdgeRouter Lite (dualcore, 500Mhz MIPS64):
Screen Shot 2020-06-06 at 11.56.00 PM.png

I don't know how they did those benchmarks, but my edgerouter lite is just as fast when doing ipsec as these wireguard results.
On ipsec I get to choose the encryption. I get it that wireguard has its uses and is better than ipsec on some aspects. But to me it is absolutely not the one size fits all vpn.

Posted: **Mon Jun 08, 2020 3:49 am**

my edgerouter lite is just as fast when doing ipsec as these wireguard results.

It looks like on the standard OS they're comparable, OpenWRT has probably some newer (less stable?) implementation. Based on the date of the post it's also possible that OWRT used kernel module while EdgeOS used userland implementation.

I deliberately didn't want to bring benchmarks published by WG itself, since even the author puts the following warning as of today:

These benchmarks are old, crusty, and not super well conducted. In the intervening time, WireGuard and IPsec have both gotten faster, with WireGuard stil edging out IPsec in some cases due to its multi-threading, while OpenVPN remains extremely slow. It is a work in progress to replace the below benchmarks with newer data.

However, even there the numbers look promising:

Screen Shot 2020-06-07 at 7.43.29 PM.png

On ipsec I get to choose the encryption. I get it that wireguard has its uses and is better than ipsec on some aspects. But to me it is absolutely not the one size fits all vpn.

And I can agree with this 101%. WG is not a magical one-fits-all, and the author itself is aware of that. Even the fact that WG deliberately tunnels IP layer only is a limiting factor for many. However, as a general tunneling protocol for HTTP/SMB/AFP, especially for road warriors on mobile it's vastly better.
The biggest gripe with IPSec is not its configuration itself when you control both ends, but attempting to match both sides. Also, after you do you will get reports that "it doesn't work, I'm in hotel X" after which you see how many pseudoadmins do DROP ALL, ALLOW TCP+UDP.

It's worth listening to https://podcast.asknoahshow.com/177 (WG part starts 16:40) - the author has a very sane approach to limitations, goals, and challenges along the way, as well as how the Linux community approached the new "revolutionary" protocol.

Posted: **Mon Jun 08, 2020 5:34 am**

@markwien
Detailed benchmarks: https://an.undulating.space/post/181227 ... enchmarks/

TL;DR - on budget EdgeRouter Lite (dualcore, 500Mhz MIPS64):
Screen Shot 2020-06-06 at 11.56.00 PM.png
I don't know how they did those benchmarks, but my edgerouter lite is just as fast when doing ipsec as these wireguard results.
On ipsec I get to choose the encryption. I get it that wireguard has its uses and is better than ipsec on some aspects. But to me it is absolutely not the one size fits all vpn.

I 100% Agree with @onnoossendrijver

WireGuard has a huge number of limitations in comparison with IPSEC, and quite a few with OpenVPN too.

It is a case of "Horses for Courses".

I will be using WireGuard for direct connectivity to VM's and Containers as it is MUCH simpler than IPSEC or OpenVPN. But for general site-to-site VPN's and for dial-in VPN's I will continue to use IPSEC.

Posted: **Sun Jul 05, 2020 12:01 pm**

I look forward to supporting wiregiard
+1

Posted: **Wed Jul 08, 2020 2:02 pm**

+1 for Wireguard

Posted: **Mon Jul 20, 2020 5:56 pm**

Personally, I'd prefer to see Slack's nebula VPN (which is based on Wireguard) included instead of stock Wireguard.

Nebula's three key benefits, as I see it are:
1) the mesh topology
2) the ability to choose different ciphers, if you want
and most importantly
3) a much more robust PKI solution for deploying at scale.

Wireguard is fine if you're setting up a few point-to-point hosts, but when you start trying to deploy and manage hundreds of nodes, it becomes cumbersome in a hurry.

Posted: **Tue Jul 21, 2020 3:15 am**

Personally I would much rather see vanilla Wireguard, simplicity and speed is all I need.

Posted: **Wed Jul 22, 2020 7:18 pm**

Personally I would much rather see vanilla Wireguard, simplicity and speed is all I need.

Which Nebula also offers. In fact, Nebula offers basically all of the benefits of Wireguard with almost none of its drawbacks. It is, essentially, an administration framework that makes Wireguard functional at scale. I'd recommend you actually look at it before dismissing it outright.

Again, Wireguard has a lot of really great properties, and it's a good pick if you need to quickly set up a couple of point-to-point tunnels. But when you start talking about needing to deploy to dozens (or in my case, several hundreds) of nodes it becomes a non-solution.

The main deployability benefit in terms of scale is the inclusion of each peer's VPN address in the certificate, meaning you don't have to edit a random text file / make a config change every time you need to add a new host - just generate a new crt/key pair, toss it on the new node and everything just works.

There are (obviously) a lot of people who have a lot of interest in the inclusion of Wireguard - and look, I use it in some personal applications, particularly on travel routers back when we were allowed to leave our homes. But in terms of how I use RouterOS professionally, switching to vanilla Wireguard is a non-starter. We only buy a few hundred Mikrotik routers a year, so I'm not big-potatoes in that regard (and we're going to continue buying them whether they include Nebula, Wireguard, or neither). But without a competent way to administer 1000+ Wireguard nodes (and no, VI does not work here), it's hard for me to get excited about its inclusion in RouterOS.

Posted: **Wed Jul 22, 2020 7:55 pm**

How large is the Nebula codebase? Wireguard is compact, this is needed in devices that are already pushing the limits of what can fit into the limited remaining memory.

(edit)
I just looked, the arm7 binary is 14.64 MB and nebula-cert is 4.23 MB

Posted: **Wed Jul 22, 2020 8:02 pm**

How large is the Nebula codebase? Wireguard is compact, this is needed in devices that are already pushing the limits of what can fit into the limited remaining memory.

Look, I'm not interested in escalating a bad-faith argument. I posted the link to the github above, if you're interested in checking it out.

(Answer: since it literally uses Wireguard for its tunnel infrastructure, it's larger than Wireguard).

Posted: **Wed Jul 22, 2020 8:04 pm**

It's not an argument, how would something this large be implemented?

Posted: **Wed Jul 22, 2020 9:13 pm**

I agree with @rooted on that. While the project looks promising it recreates many problems of OpenVPN/IPSec like PKI management. WG is meant to plug to other things (like DHCP or OSPF) and by small, light, and kernel-level. Additionally the Nebula is still work-in-progress with no client for iOS, which like it or not, is extremely popular.

Additionally, while there are certain use cases for Nebula, it's not something a huge community is surrounded around. There's a reason why Linux nor MT jump on shines new toys. Nebula by itself, as an ADDITION on top of WG clocks over 16,000 lines of code. WG in comparison is around 2,000. This is one of the arguments why WG become popular: it can be easily audited, Nebula can't.

Posted: **Wed Jul 22, 2020 9:45 pm**

Wireguard as a stand alone tunnel type in mikrotik with a simply key generator that can be copied/pasted like you'd do setting up an EoIP tunnel is immensely useful without any added frills. If mikrotik would add that then it would have the baseline features for adding nebula or other wireguard based things later.

Please please add this and please please please allow us to set src-address and/or routing table for the tunnel to make redundant connections easy to manage.

Posted: **Wed Jul 22, 2020 9:47 pm**

It's not an argument, how would something this large be implemented?

Presumably the same way you implement anything on an embedded environment - through a lot of compile optimization and stripping out parts that aren't fully necessary for the actual CPU you are targeting or functionality you're not interested in.

A quick look at the nebula build scripts confirms that there are no size optimizations in the linker flags. A compile using -s -w knocked about 40% off the size of the executable on AMD64. Running it through UPX kicked it down to 24% of its original size (4,225,512 vs 17,579,597). These optimizations took me 4 minutes. It's also worth noting that Go binaries are all statically linked, which increases the file size considerably compared to a dynamically linked C/C++ binary. One assumes that you could dynamically link using gccgo and experience additional reductions.

Then there's the matter of functionality reduction / combination. A RouterOS implementation would almost certainly strip out the SSH-based management server. Parts of nebula-cert would likely be implemented in RouterOS's already existing CA. Or as Mikrotik are wont to do, they might not use the stock implementation at all (*cough* OpenVPN *cough*) and roll their own. All of these are possibilities.

Is all of this more difficult than integrating Wireguard alone? Sure. Absolutely. Is it impossible? I doubt it.

I agree with @rooted on that. While the project looks promising it recreates many problems of OpenVPN/IPSec like PKI management. WG is meant to plug to other things (like DHCP or OSPF) and by small, light, and kernel-level. Additionally the Nebula is still work-in-progress with no client for iOS, which like it or not, is extremely popular.

Additionally, while there are certain use cases for Nebula, it's not something a huge community is surrounded around. There's a reason why Linux nor MT jump on shines new toys. Nebula by itself, as an ADDITION on top of WG clocks over 16,000 lines of code. WG in comparison is around 2,000. This is one of the arguments why WG become popular: it can be easily audited, Nebula can't.

For starters, Wireguard isn't 2,000 lines of code. It's over twice that. Also, I'd push back on your claim that WG is popular because "it can be easily audited" in a couple of ways. Most importantly, whether it can be easily audited or not, it hasn't been. Second, I suspect a one-man-shop project like WG, well coded though it may be, is less likely to receive a formal audit than a project backed by a major internet presence like Slack. Third, the fact that you weren't aware of the actual size of WG's code makes me wonder whether you've bothered to actually look at it yourself at any level. And finally, when you say, "There's a reason why Linux nor MT jump on shiny new toys" - Wireguard is basically the definition of a shiny new toy.

When you suggest that "[Nebula] recreates many problems of OpenVPN/IPSec like PKI management..." I think, again, you really just don't understand what's involved in deploying something like this at scale. Is it "easier" when you're setting up 5 nodes to copy in a few public keys to your server config than it is to set up a PKI? Sure. But that kind of solution doesn't scale when you're talking about managing 1,500 nodes. I can barely keep track of which device is associated with which private key on the minor Wireguard installations I have - I have no idea how you would systematically manage something like that in production. Once you reach a certain number of nodes, managing a PKI becomes far easier than exchanging private keys with both hosts. A solution like Wireguard that requires you to update your server configuration / restart the instance every time you add a node is simply unacceptable.

Again, Wireguard has a lot of really nice properties. I like it, and use it for a number of applications. But there's a big difference between tinkering in a home lab with a few hosts and deploying something to hundreds or thousands of hosts in production. Wireguard is great for the first use case, but it's a non-starter for the second.

You also state that WG is meant to plug into DHCP. Unless Jason has changed his approach, I highly doubt that. He's on record as saying there are no plans to support dynamic VPN address assignments in WG, because (and I can't find the quote right now) "static addresses are a better way to design your network."

At any rate, I've stated my preference. Mikrotik will either listen, or they won't. Wireguard has an almost religious following now, and it's becoming difficult to hold any kind of rational discussion about the matter. I should have known better.

Best...

Posted: **Mon Jul 27, 2020 11:52 pm**

It's not an argument, how would something this large be implemented?
...

At any rate, I've stated my preference. Mikrotik will either listen, or they won't. Wireguard has an almost religious following now, and it's becoming difficult to hold any kind of rational discussion about the matter. I should have known better.

Best...

+1 Wireguard

It's not a fair assessment to label the feature request of Wireguard as a "religious following". That's actually a very short-sighted/narrow understanding of people's needs in the time of a pandemic. The very practical, safe, and reasonable approach would be to implement Wireguard in RouterOS as soon as possible. Unless the current VPN implementations from Mikrotik checks all the same boxes of requirements and Wireguard doesn't, I say 'why not'?

Posted: **Tue Aug 04, 2020 2:01 pm**

+1 for WireGuard!

Posted: **Tue Aug 04, 2020 9:25 pm**

Give them a bit of time at least - they have already basically said they are adding it.

Posted: **Wed Aug 05, 2020 2:13 pm**

Screenshot from 2020-08-05 14-13-29.png

Posted: **Wed Aug 05, 2020 3:20 pm**

This is becoming exciting!

Posted: **Wed Aug 05, 2020 3:21 pm**

nice

Posted: **Wed Aug 05, 2020 4:28 pm**

This is getting interesting!

Posted: **Wed Aug 05, 2020 6:55 pm**

Look at that throughput! Not bad for the lack of "hardware offloading".

Posted: **Wed Aug 05, 2020 7:24 pm**

I would bet that bandwidth test is being used to generate this flow and that's affecting the throughput a bit too. Pretty impressive IMO.

Posted: **Wed Aug 05, 2020 7:53 pm**

I would bet that bandwidth test is being used to generate this flow and that's affecting the throughput a bit too. Pretty impressive IMO.

Exactly.

Posted: **Thu Aug 06, 2020 12:22 am**

That's amazing speed from a hAP AC², thank you for sharing the progress.

Posted: **Thu Aug 06, 2020 3:09 pm**

I registered an account just to look at the attachment... and it was worth it!

Posted: **Fri Aug 07, 2020 12:39 pm**

Screenshot from 2020-08-05 14-13-29.png

Hi Emils,

Is there any chance we could have access to this?
We are really crucially depending on wireguard and anything that could make it work, even a alpha/beta version would be greatly appreciated.

Thanks
Stan

Posted: **Fri Aug 07, 2020 11:40 pm**

+1 for WireGuard

Posted: **Sat Aug 08, 2020 3:27 pm**

Great! Looks like it is about as fast as IPSec...
At least on ARM. Wondering what numbers look like on mipsbe and tile.

Posted: **Sat Aug 08, 2020 5:27 pm**

I registered an account just to look at the attachment... and it was worth it!

me too!

Posted: **Sun Aug 09, 2020 2:25 pm**

Finally. All I could dream for

Posted: **Tue Aug 11, 2020 5:05 pm**

Can't wait.. and this post has 35 000 views already

Posted: **Tue Aug 11, 2020 6:06 pm**

Looks like some great activity already...+1 for WireGuard as well.

Posted: **Thu Aug 13, 2020 2:59 pm**

DID you know that WireGuard now runs under Windows 10, macOS, IOS, Android and MANY flavors of Linux
https://www.wireguard.com/install/

Amazing !!!

Posted: **Fri Aug 14, 2020 9:05 am**

DID you know that WireGuard now runs under Windows 10, macOS, IOS, Android and MANY flavors of Linux
https://www.wireguard.com/install/

Amazing !!!

Part of what makes it so attractive, portability and ease of setup and use.

Posted: **Fri Aug 14, 2020 2:17 pm**

Kudos to the team, it's day and night compared to OpenVPN

Posted: **Sun Aug 16, 2020 2:01 pm**

Oh man that screenshot... Can't wait ! Good luck with the v7 development !

Posted: **Fri Aug 21, 2020 3:20 pm**

Great to see this now released in beta2. I've done some testing and it seems to work very nicely!

Only issue I've seen so far is that it doesn't seem to be possible to enter a port number for your peer's endpoint in Winbox - it fails validation. In the CLI this works just fine though.

Posted: **Fri Aug 21, 2020 8:21 pm**

For anyone not subscribing to v7 updates the beta2 showed on the screenshot is publicly available now: viewtopic.php?f=1&t=152003#p812227

Posted: **Fri Aug 21, 2020 10:15 pm**

Omg, god bless developers, waiting for the WIREGUARD so much !!!!!!!!!!!!!!!, subscribed for the updates !

Posted: **Sun Aug 23, 2020 2:53 am**

Aaaanndd... it's works!
Android client connected to hAP ac2 - speedtest 150/150Mbps, MT CPU ~60%.

Posted: **Sun Aug 23, 2020 3:02 am**

Rb4011 yields me about 300Mbps through a 1Gbps pipe.

Posted: **Sun Aug 23, 2020 3:39 am**

Rb4011 yields me about 300Mbps through a 1Gbps pipe.

How are you benchmarking that?

Posted: **Sun Aug 23, 2020 3:58 am**

Rb4011 yields me about 300Mbps through a 1Gbps pipe.
How are you benchmarking that?

I benchmarked using iperf. I have a Linux VM at a cloud provider functioning as the "client" to my Linux box within my home network functioning as the "server".
These results were just taken and are slightly lower than when the network is idle. The family is streaming a video show right now.


$ iperf3 -c 10.10.10.7 -t 10

Connecting to host 10.10.10.7, port 5201
[  4] local 10.10.13.2 port 45388 connected to 10.10.10.7 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  2.62 MBytes  22.0 Mbits/sec    0    152 KBytes
[  4]   1.00-2.00   sec  5.33 MBytes  44.8 Mbits/sec    0    357 KBytes
[  4]   2.00-3.00   sec  10.1 MBytes  84.6 Mbits/sec    0    778 KBytes
[  4]   3.00-4.00   sec  22.5 MBytes   189 Mbits/sec    0   1.77 MBytes
[  4]   4.00-5.00   sec  30.0 MBytes   251 Mbits/sec    0   2.63 MBytes
[  4]   5.00-6.00   sec  36.2 MBytes   305 Mbits/sec  111   2.21 MBytes
[  4]   6.00-7.00   sec  36.2 MBytes   304 Mbits/sec    0   2.43 MBytes
[  4]   7.00-8.00   sec  37.5 MBytes   315 Mbits/sec    1   1.81 MBytes
[  4]   8.00-9.00   sec  27.5 MBytes   231 Mbits/sec    0   1.92 MBytes
[  4]   9.00-10.00  sec  31.2 MBytes   262 Mbits/sec    0   2.00 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   239 MBytes   201 Mbits/sec  112             sender
[  4]   0.00-10.00  sec   238 MBytes   200 Mbits/sec                  receiver

Posted: **Sun Aug 23, 2020 5:09 am**

Aaaanndd... it's works!
Android client connected to hAP ac2 - speedtest 150/150Mbps, MT CPU ~60%.

I just did a SMB file transfer from my phone to my NAS over the wireguard tunnel and got 200Mbps with about 65-75% CPU usage. Curious to see what would happen if I did a test where my phone's WiFi wasn't a possible bottleneck! But also too lazy to get up off the couch! (Configured the tunnel from my phone lol)

Posted: **Sun Aug 23, 2020 4:28 pm**

Rb4011 yields me about 300Mbps through a 1Gbps pipe.
How are you benchmarking that?

I benchmarked using iperf. I have a Linux VM at a cloud provider functioning as the "client" to my Linux box within my home network functioning as the "server".
These results were just taken and are slightly lower than when the network is idle. The family is streaming a video show right now.


$ iperf3 -c 10.10.10.7 -t 10

Connecting to host 10.10.10.7, port 5201
[  4] local 10.10.13.2 port 45388 connected to 10.10.10.7 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  2.62 MBytes  22.0 Mbits/sec    0    152 KBytes
[  4]   1.00-2.00   sec  5.33 MBytes  44.8 Mbits/sec    0    357 KBytes
[  4]   2.00-3.00   sec  10.1 MBytes  84.6 Mbits/sec    0    778 KBytes
[  4]   3.00-4.00   sec  22.5 MBytes   189 Mbits/sec    0   1.77 MBytes
[  4]   4.00-5.00   sec  30.0 MBytes   251 Mbits/sec    0   2.63 MBytes
[  4]   5.00-6.00   sec  36.2 MBytes   305 Mbits/sec  111   2.21 MBytes
[  4]   6.00-7.00   sec  36.2 MBytes   304 Mbits/sec    0   2.43 MBytes
[  4]   7.00-8.00   sec  37.5 MBytes   315 Mbits/sec    1   1.81 MBytes
[  4]   8.00-9.00   sec  27.5 MBytes   231 Mbits/sec    0   1.92 MBytes
[  4]   9.00-10.00  sec  31.2 MBytes   262 Mbits/sec    0   2.00 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   239 MBytes   201 Mbits/sec  112             sender
[  4]   0.00-10.00  sec   238 MBytes   200 Mbits/sec                  receiver

Not bad. I mean it's not really matching hardware accelerated ipsec on that specific hardware but pretty good for CPU encryption.

Posted: **Sun Aug 23, 2020 4:34 pm**

Rb4011 yields me about 300Mbps through a 1Gbps pipe.
How are you benchmarking that?
I benchmarked using iperf. I have a Linux VM at a cloud provider functioning as the "client" to my Linux box within my home network functioning as the "server".
These results were just taken and are slightly lower than when the network is idle. The family is streaming a video show right now.
Code: Select all
$ iperf3 -c 10.10.10.7 -t 10

Connecting to host 10.10.10.7, port 5201
[  4] local 10.10.13.2 port 45388 connected to 10.10.10.7 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  2.62 MBytes  22.0 Mbits/sec    0    152 KBytes
[  4]   1.00-2.00   sec  5.33 MBytes  44.8 Mbits/sec    0    357 KBytes
[  4]   2.00-3.00   sec  10.1 MBytes  84.6 Mbits/sec    0    778 KBytes
[  4]   3.00-4.00   sec  22.5 MBytes   189 Mbits/sec    0   1.77 MBytes
[  4]   4.00-5.00   sec  30.0 MBytes   251 Mbits/sec    0   2.63 MBytes
[  4]   5.00-6.00   sec  36.2 MBytes   305 Mbits/sec  111   2.21 MBytes
[  4]   6.00-7.00   sec  36.2 MBytes   304 Mbits/sec    0   2.43 MBytes
[  4]   7.00-8.00   sec  37.5 MBytes   315 Mbits/sec    1   1.81 MBytes
[  4]   8.00-9.00   sec  27.5 MBytes   231 Mbits/sec    0   1.92 MBytes
[  4]   9.00-10.00  sec  31.2 MBytes   262 Mbits/sec    0   2.00 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   239 MBytes   201 Mbits/sec  112             sender
[  4]   0.00-10.00  sec   238 MBytes   200 Mbits/sec                  receiver
Not bad. I mean it's not really matching hardware accelerated ipsec on that specific hardware but pretty good for CPU encryption.

Interesting. Now I'll have to perform a ipsec benchmark later today. I'm curious to see the delta.

Posted: **Sun Aug 23, 2020 4:40 pm**

Interesting. Now I'll have to perform a ipsec benchmark later today. I'm curious to see the delta.

rb4011 has the Annapurna Labs 21400 which is an ipsec beast. Do AES256CBC w/ SHA256.

Posted: **Mon Aug 24, 2020 12:25 am**

I'm not understanding these low speeds when the test emils did above was from a hAP ac² and was nearly 430 Mbps.

Posted: **Mon Aug 24, 2020 12:33 am**

I'm not understanding these low speeds when the test emils did above was from a hAP ac² and was nearly 430 Mbps.

Not sure what he was testing with. I was doing SMB which may very well be slower over wireguard compared to a dedicated speed test which you optimize for the protocol.

Posted: **Mon Aug 24, 2020 12:48 am**

Not sure what he was testing with. I was doing SMB which may very well be slower over wireguard compared to a dedicated speed test which you optimize for the protocol.

One must always remember that the weakest link rate will always determine the vpn throughput;
For example .... router1 in location1 has a symmetrical connection of 1Gbps/1Gbps
......................... router2 in location2 has a asymmetrical connection of 1Gbps/50Mbps

So in the above scenario the very best VPN throughput cannot exceed 50Mbps between router1 and router2

Posted: **Mon Aug 24, 2020 6:33 am**

Could also have some debug code enabled or the compiler may be using conservative or non-threading flags.

Can you guys run cpu profile while you test?

I’m not entirely sure if we should expect multi-threading for a single tunnel. Could potentially get these speeds simultaneously on 4 separate tunnels too.

Posted: **Mon Aug 24, 2020 8:42 am**

Could also have some debug code enabled or the compiler may be using conservative or non-threading flags.

Can you guys run cpu profile while you test?

I’m not entirely sure if we should expect multi-threading for a single tunnel. Could potentially get these speeds simultaneously on 4 separate tunnels too.

Unfortunately, I'm not familiar with CPU profiling if that's some sort of specific tool. I will say that the fact that CPU load is greater than 25% indicates to me that it is at least taking advantage of multiple cores.

Using SMB file transfer on my W10 machine to my NAS, I was able to get ~240 download

Interestingly Uploading to the NAS was faster.

It's possible that Read/Write speed of my NAS has an affect here. I doubt it's the network as basically my W10 desktop is wired to the hAP ac2 and that is wired directly to the NAS (Linux server).

Installing a librespeed docker really quick on my server, I was able to get faster results and in the interface stats, it was even higher than the screenshot said. It's a burst though and I'm not really sure how to configure this server to run longer tests. That said, they are pretty consistent on subsequent runs.

Also, so there's no question about the underlying link quality, here's the same test, but with not going through the tunnel.

Posted: **Mon Aug 24, 2020 9:25 am**

There are many things that will have high impact on the throughput. Some of them:

proper testing method - you want to test the routers throughput as a device that is between two other devices that perform the test. Generating or processing the traffic on the same router will reduce the throughput because the device will have to do other things beside encrypting/decrypting and routing.
My test setup:
https://wiki.mikrotik.com/wiki/Manual:T ... mance_test
other configuration on the device - mostly connection tracking, firewall and QoS has the highest impact on the throughput of your router. No other configuration in my case.
the kind of traffic used - TCP and UDP has different characteristics. In most cases UDP will be a lot faster. TCP shows its downside in high latency links due to small window sizes and packet losses. My test was performed in LAN network with UDP traffic.

Here is another test with mipsbe hAP ac.

Posted: **Mon Aug 24, 2020 10:06 am**

There are many things that will have high impact on the throughput. Some of them:

proper testing method - you want to test the routers throughput as a device that is between two other devices that perform the test. Generating or processing the traffic on the same router will reduce the throughput because the device will have to do other things beside encrypting/decrypting and routing.
My test setup:
https://wiki.mikrotik.com/wiki/Manual:T ... mance_test

other configuration on the device - mostly connection tracking, firewall and QoS has the highest impact on the throughput of your router. No other configuration in my case.

the kind of traffic used - TCP and UDP has different characteristics. In most cases UDP will be a lot faster. TCP shows its downside in high latency links due to small window sizes and packet losses. My test was performed in LAN network with UDP traffic.

Here is another test with mipsbe hAP ac.

Can you tell us a little more about your traffic generator? What size UDP packets? What's the MTU you're using between the two routers that is handling the wireguard tunnel?

I agree that you can't use the router the generate traffic, and I'm not in my case. I tried iperf3 and didn't see any better performance with UDP.

The largest variable I see is the other end of my tunnel is a windows 10 client. It's possible that is slower than the router implementation, but my desktop PC has quite a beefy cpu, so that doesn't seem to be super likely to be the case (i7-9700k)

Posted: **Mon Aug 24, 2020 10:39 am**

+1 for Wireguard

Posted: **Mon Aug 24, 2020 1:23 pm**

I am actually using Wireguard since longer and therefore completely eliminated all other types of access like L2TP/IPsec and OVPN.
However I am super unhappy with operating a dedicated environment to provide the termination point for wireguard including all routing stuff.

And of course I am happy with Mtik but not for every price, esp. ease of integration and maintenance.
For me it is a matter of competitive advantage.

+1 for Wireguard on Mikrotik
+1 for more recent kernel version (efficiency, features, maturity) "stable frontrunner"

/Uwe

Posted: **Mon Aug 24, 2020 5:07 pm**

Testing on a RB951G (mipsbe with 600MHz single core) with a 100/40 MBit/s uplink: I could do 90/38 MBit/s through the tunnel - with bandwidth-test on the device itself.
Pretty impressive given that IPSec barely does 20 MBit/s...

So can't wait to see WireGuard in a stable version... I hope it does not take too long for RouterOS v7 to move.

Posted: **Tue Aug 25, 2020 11:11 pm**

Has anyone been able to set mikrotik as a peer to another existing wireguard server?

I'm trying to set it up but I can't get it to work and in the current beta I can't get wireguard logging to better understand what is happening.

Posted: **Wed Aug 26, 2020 2:06 am**

It's not working from webfig (haven't tried winbox), but it's working from console, just like that

/interface wireguard
add listen-port=xxx mtu=xxx name=wireguard1 private-key=\
    "xxx"
/interface wireguard peers
add allowed-address=192.168.x.0/24,2xxx:::/64 endpoint=\
    xxx:xxx interface=wireguard1 persistent-keepalive=25 \
    public-key="xxx"

Posted: **Thu Aug 27, 2020 9:34 pm**

Ok, this is getting to me.
First it was socks5, how long did that take?
Now I've been waiting forever for wireguard to show up. Still not there in stable and that kernel can be a much more recent version.

So, I've had it, I'm moving on. What kind of router would ya'll recommend ?

Posted: **Thu Aug 27, 2020 10:28 pm**

First it was socks5, how long did that take?

Maybe because interest in SOCKSv5 was absymal? The FR on the forum has 30 posts in 10 years where WG got >150 in a couple of months.

Now I've been waiting forever for wireguard to show up. Still not there in stable and that kernel can be a much more recent version.

WG was officially appeared in the Linux Kernel with 5.6 released in March 2020 - you seem to be very impatient. Running the client side implementation is not really a feasible option on a router.
The kernel version isn't old like it used to be. I'm sure they have a process now to deliver more recent updates looking at the progress in v7. However, don't expect a bleeding edge kernel on non-general purpose device.

So, I've had it, I'm moving on. What kind of router would ya'll recommend ?

It's good you're moving on if you're not satisfied, nobody is forcing you to use MT. Your entire post history is two posts with sarcastic complains, so I think you're on a wrong forum to ask for a purchase advice.

Posted: **Fri Aug 28, 2020 4:55 am**

First it was socks5, how long did that take?
Maybe because interest in SOCKSv5 was absymal? The FR on the forum has 30 posts in 10 years where WG got >150 in a couple of months.

Now I've been waiting forever for wireguard to show up. Still not there in stable and that kernel can be a much more recent version.
WG was officially appeared in the Linux Kernel with 5.6 released in March 2020 - you seem to be very impatient. Running the client side implementation is not really a feasible option on a router.
The kernel version isn't old like it used to be. I'm sure they have a process now to deliver more recent updates looking at the progress in v7. However, don't expect a bleeding edge kernel on non-general purpose device.

So, I've had it, I'm moving on. What kind of router would ya'll recommend ?
It's good you're moving on if you're not satisfied, nobody is forcing you to use MT. Your entire post history is two posts with sarcastic complains, so I think you're on a wrong forum to ask for a purchase advice.

100% agree.

Let's stop the discussion of this here though. This is a thread about Wireguard support for MT. The above discussion is irrelevant.

Posted: **Fri Aug 28, 2020 8:38 am**

Some of the above posters have not realised that Wireguard has been added to RouterOS already.
It can't be put into a "Stable" RouterOS release, since it requires a new kernel, and is inherently not "stable" if we replace the core of the OS.

Posted: **Fri Aug 28, 2020 4:46 pm**

Has anyone been able to set mikrotik as a peer to another existing wireguard server?

I'm trying to set it up but I can't get it to work and in the current beta I can't get wireguard logging to better understand what is happening.

I was trying to connect to an already live wireguard server. I wrote the address and port through the terminal, because WebFig does not have a Port field. But tcpdump on the server does not see calls to this port. But connection can established from the client machine BEHIND the mikrotik. I feel a little disappointed

Posted: **Mon Aug 31, 2020 8:30 pm**

Has anyone been able to set mikrotik as a peer to another existing wireguard server?

I'm trying to set it up but I can't get it to work and in the current beta I can't get wireguard logging to better understand what is happening.
I was trying to connect to an already live wireguard server. I wrote the address and port through the terminal, because WebFig does not have a Port field. But tcpdump on the server does not see calls to this port. But connection can established from the client machine BEHIND the mikrotik. I feel a little disappointed

That sounds like a firewall issue to me. MikroTik doesn't inherently have a "behind" or "in front of". That only really comes into play when you have your firewall.

Posted: **Mon Aug 31, 2020 8:44 pm**

Has anyone been able to set mikrotik as a peer to another existing wireguard server?

Yes. I had an old experimental setup: in a computer at home one peer, a port directed in the router, and I used to test from my laptop.

Now I transfered my laptop configuration to my mikrotik travel router and it started working instantly.

I am very busy currently but I'm really looking forward to setting up a proper network...

What I mostly love is that it is not chatty at all. Basically the "dial-on-demand" characteristic of the ppp VPNs is built-in (unless you set up keepalive). And the connection is restored in just two one roundtrip.

Posted: **Wed Sep 09, 2020 3:45 pm**

Has anyone been able to set mikrotik as a peer to another existing wireguard server?
Yes. I had an old experimental setup: in a computer at home one peer, a port directed in the router, and I used to test from my laptop.

Now I transfered my laptop configuration to my mikrotik travel router and it started working instantly.

I am very busy currently but I'm really looking forward to setting up a proper network...

What I mostly love is that it is not chatty at all. Basically the "dial-on-demand" characteristic of the ppp VPNs is built-in (unless you set up keepalive). And the connection is restored in just two one roundtrip.

Do you have the CLI commands used? I tried to replicate the config I have in my Mikrotik in the Peer settings but I don't see anything in my server, no connection request. Also, checking in the Wireguard Documentation, when connecting to a server, the interface should not have a Listening Port setting. But in order create an interface in Mikrotik I do need to provide a Listening Port which kinda goes against the official Mikrotik documentation.

Lastly, being able to provide a host name instead of an IP address would be crucial...

Posted: **Wed Sep 30, 2020 11:39 pm**

+1 for Wireguard

Posted: **Thu Oct 01, 2020 6:50 pm**

+1 for Wireguard

It's already implemented and working quite nicely in 7.1beta2 :)

Posted: **Mon Nov 02, 2020 10:25 pm**

If some one is interested and finds useful, I put together a quick script that gets a Wireguard interface and updates the endpoint IP address according to the IP address the domain resolves. This is great for who is running their wireguard server behind a Dynamic IP address.

Hopefully we have a cleaner solution in the next beta version with the endpoint being able to be provided as a host name.

:local resolvedIP [:resolve "<domain>"];
:local interface 0;
:local currentIP [/interface/wireguard/peers get $interface endpoint];

:if ([:find $currentIP $resolvedIP] < 0) do={
    /log info "IP Changed to $resolvedIP"
    /log info ($resolvedIP . ":51820");
    /interface/wireguard/peers set $interface endpoint=($resolvedIP . ":51820");
    /log info "Wireguard Peer $interface endpoint updated";
    /interface/wireguard disable $interface
    /interface/wireguard enable $interface
}

Posted: **Mon Nov 09, 2020 2:45 pm**

Has anyone been able to set mikrotik as a peer to another existing wireguard server?

I'm trying to set it up but I can't get it to work and in the current beta I can't get wireguard logging to better understand what is happening.

Hi, yes. I have a working peer of my Mikrotik ROS to a debian server running wireguard.
You will find my example setup here (for the client):
viewtopic.php?f=1&t=168231

Posted: **Sun Mar 14, 2021 9:25 pm**

111.png

Hello everyone!
Is there a possibility in the field "endpoint" from peer register two ip's?

Posted: **Mon Apr 11, 2022 1:51 pm**

It would be great if we could generate the QR Code for Clients from the Mikrotik Admin UI.

MikroTik

Feature Request - Wireguard Protocol

Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol

Re: Feature Request - Wireguard Protocol