I’ve got a Mikrotik virtual machine (P10 Licence) running on Amazon AWS with a Wireguard server. it’s a t3.micro instance, which is supposed to give me up to 5Gbps bandwidth. When I do a bandwidth test (tcp both directions) from the peer to the server I’m not getting anything like that speed though. The peer is connected to a fibre line with (supposedly) 8Gbps up and 2Gbps down speeds, so I should be getting more than what I’m seeing. I know the speeds shown are pretty good by most people’s standards, but if I’m paying (at both ends) for faster speeds, I want to be sure I’m getting what I pay for. Any ideas please? Thanks in advance.
The 5 Gbps is probably the BEST CASE (up to 5Gbps of NETWORKING performance, 0 guarantees) => do not confuse "wireguard performance with basic network performance of the t3 vm)
Perhaps there is specific tuning that is possible to increase it a bit more.
@Slartybart: As WireGuard relies entirely on ChaCha20, which is a pure software encryption, throughput depends directly on the CPU power, so a slower CPU means slower throughput. For maximum throughput on AWS, consider using IPSec, though be aware that there might be a throughput cap depending on the model configuration you’re using.
A normal non-wireguard mikrotik to AWS bandwidth test seems to cap at around 2Gbps before it gives up. I guess that too is a limitation of either the CHR at my end or the AWS processor, but it could be an isp limitation. I was never really convinced their ‘offer’ speed was likely to happen. It’d be nice to know though.
I shouldn’t really complain about the Wireguard speeds I’m getting, they are fast enough for at least a few people to stream 4k movies at once, after all. I’ll have a play around with an ipSec connection though and see if that helps, but maybe I should just be content.
Thanks again.
Well, I’m not sure what you’re basing your claims on, but IPsec with hardware acceleration is always faster than WireGuard— and that’s a fact!
Also, all AWS instance types, like EC2, ECS, and EKS, use either x86_64 or Graviton processors and which support IPSec AES-NI hardware acceleration. This works for both guest operating systems and AWS internal networking (Amazon VPC).
Streaming 4K/UHD with the standard h.265 codec uses about 15 Mbps per stream, so you should have plenty of bandwidth for multiple streams (like at least 25 at the same time) with the throughput you’re getting on WireGuard. Just curious, why do you need AWS for streaming anyway?
Haha, yeah, that article was really ‘professional,’ but hey, not bad for a basement hacker who clearly has no clue whatsoever about AES hardware acceleration. Nice try though!
Larsa:
“Streaming 4K/UHD with the standard h.265 codec uses about 15 Mbps per stream, so you should have plenty of bandwidth for multiple streams (like at least 25 at the same time) with the throughput you’re getting on WireGuard. Just curious, why do you need AWS for streaming anyway?”
You are absolutely right… the bandwidth I’m getting through the Wireguard tunnel is absolutely fine for anything we are likely to throw at it… it does service four houses though.. The reason I’ve used an AWS instance to host it is simply this: My home network in London, which is connected to ‘the UK’s fastest residential broadband network’, allegedly, gives only 100Mbps upload speeds. So basically when connecting to our home setup the bottleneck was our internet connection in London. The AWS instance removes that bottleneck as their upload speeds are much faster than I was able to provide connected to my Mikrotik router at home. I guess also there is a slighty irrational feeling that everything has to be as fast as it possibly can be. Partly, I suppose, because I’m paying for those speeds (at one end of the tunnel at least) and I’d like to think I’m using them.
PS… I tried to set up an Ipsec tunnel and completely borked the whole set up, locking me out completely. Fortunately I was able to reconnect via a Zerotier connection (backup route two of three) and revert to a backup configuration file… I think I’ll leave it as it is for now! Note to self: Safe Mode is a really clever thing!
There will be a cap because it’s decade old CPU with AES-NI being shared between several neighboring VMs on the same node. Honestly I’m impressed how good OP’s Wireguard performance is right now
IPSEC IKEv2 normally uses AES encryption algorithm which should be hardware accelerated by default on some Intel CPUs (even as old as 3rd generation eg. Ivy Bridge).
Thanks again for everyone’s input. As I managed to completely mess up the router trying (remotely) to configure an IPsec tunnel I’ve decided to put this to one side for now. I don’t want to risk messing up again and not being able to recover the remote network, as it’s a twenty hour return trip to flick the reset button! I’ll just have to be content with what we’ve got for now, although by no means is the current wireguard tunnel speed slow! Besides, there’s no-one actually using the remote network and unlikely to be anyone there for quite some time.
@Slartybart: Yeah, you’ll probably be just fine sticking with WireGuard. Another reason to go with it is that it’s much easier to manage than IPsec if you’re not experienced. If you somehow need maximum throughput, you might want to look into getting IPsec to work with hardware acceleration.
@holvoetn: I can’t shake this déjà vu—feels like we’ve been down this road before, doesn’t it? Hmm... Anyhow, it’s a well-known fact among networking pros how and when IPsec hardware acceleration actually works. For instance:
IPsec hardware acceleration is required on both ends (shocker, right?).
There’s a reason why AWS and all major cloud providers support IPsec hardware acceleration—it’s not just for show.
IPsec with hardware acceleration (on both ends, obviously) will always be faster than WireGuard—not exactly rocket science.
And since WireGuard lacks hardware acceleration, it’s rarely seen in business-critical solutions as a preferred L3 tunnel—not a very big surprise.
It’s one of those “obvious to anyone paying attention” kind of things.
Just my ever-so-humble opinion, naturally. Cheers!
[quote=wfburton post_id=1110953 time=1732470096 user_id=215408]
… MiktoTik routers don’t have an encryption chip or an acceleration chip. So it’s a mute point here.
[/quote]
Actually you are wrong
In all my testing WG outperforms IPsec with acceleration by a factor of 2 and in some case a factor of 3 … IPsec is excellent - I have many clients who are IPsec bound plus I have many more clients who are WireGuard Bound
Perhaps before you put your foot in your mouth you should check the hardware specs of all the Tik Routers —
IPSec has its place in the enterprise world, but here in home soho user land, wireguard is easier to setup and reasonably fast and secure.
Sure it takes a hit but looking at IPSEC stats on the MT routers, its not a shining star either.
I trust mozerd, who deals with a wide variety of NON enterprise, REAL live customers, who are no less demanding of security and performance.
So if Larsa you are saying go buy two VPN routers with ipsec chips, then that would be viable.
Suggest the FortiGate FortiWiFi 40F Series - 4.4Gbps throughput for ipsec. ONLY about $350 too.
As for wfburton… you keep butting into these threads with little experience and bonehead advice. Suggest you sit back a while and refrain from jumping in where you have no clue.
RB4011 series - amazingly powerful routers with ten Gigabit ports, SFP+ 10Gbps interface and IPsec hardware acceleration for a great price!
Its ipsec results are around the 450Mpbs mark.
Of note the RB5009 are in the 500Mbps area, but doesnt state any ipsec hardware acceleration, wonder how it gets those numbers, fairy dust I guess.
The ccr2004 gets around 930Mbps ipsec results…
