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.
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.
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
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.
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:Tools/Traffic_Generator#IpSec_tunnel_performance_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)
+1 for Wireguard
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
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.
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.
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"
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 ?
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.
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.
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.
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.
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.