No smartypants, connections have the connection flag, this one doesn’t.
My point was it’s not clear and there is more subtlety here… Might be the DHCP client polling? Now whether that’s a connection in this terminology, IDK.
But I like feature.
I thought I was the only one noticing a performance drop in Wireguard
Has the “possible SYN flooding on tcp port 53” issue been solved?
Since WireGuard relies entirely on software-based encryption (ChaCha20), speed is limited by the endpoint with the weakest CPU. It’s good for home setups and out-of-band management for a single connection, but for VPN concentrators where high throughput and scalability are required, IPsec with hardware offload is still the only practical option.
I don’t agree with this. If you want to say, “vpn concentrators where high throughput and scalability are required, ipsec with offload is the only practical solution on RouterOS” maybe that is true. But if we are talking hardware/software solutions outside of what Mikrotik provides etc, then this certainly isn’t the case. Additionally, I believe @federalbr is indicating there IS a performance drop similar to what I have tested and shown in my post above whereas you were saying that you have not seen any Wireguard performance regressions.
I don’t agree with this. If you want to say, “vpn concentrators where high throughput and scalability are required, ipsec with offload is the only practical solution on RouterOS” maybe that is true. But if we are talking hardware/software solutions outside of what Mikrotik provides etc, then this certainly isn’t the case. Additionally, I believe @federalbr is indicating there IS a performance drop similar to what I have tested and shown in my post above whereas you were saying that you have not seen any Wireguard performance regressions.
So… a programable SIM card?
My comment was specifically in the context of Mikrotik ROS, where IPsec provides hardware offload. WireGuard on the same platform and with the same number of connections will have has scalability issues due to being CPU-bound, and that applies also to all platforms and architectures on the market.
To make WireGuard perform well with a large number of connections, you need massive CPU power (just look at the VPN providers). So yeah, performance will obviously vary depending on hardware, software and traffic patterns.
Bottom line: WireGuard is perfect for the advanced home user and OOB management, but not really an option when it comes to scalability. Anyone suggesting otherwise hasn’t run it in production or high-demand environments. But that’s another discussion.
As for @federalbr’s point, I’m not denying that performance issues actually can occur, just noting that in our case we haven’t observed any regressions at all, and we have plenty of OOB connections that are monitored 24/7.
So if you’re sure about the performance regressions, gather some facts and open a ticket with support. Just saying it feels slow isn’t going to cut it.
I agree that with Mikrotik’s current offerings w.r.t Wireguard are not the best choice if your looking for high throughout and massive scalability. In regards to the performance regression, I did multiple tests and submitted a ticket already.
On the topic of broader applications of Wireguard using what is available in the market, you absolutely can (and with relative ease) deploy a high throughout and scalable VPN concentrator based on Wireguard alone. Sure one can nitpick the details of managing keys (even though multiple tools exist for this) or the fact that some of the tooling built into other VPNs like OpenVPN (DHCP etc etc) doesn’t exist natively with Wireguard. At the end of the day, Wireguard is absolutely a reasonable and performant option for any kind of production environment regardless of the demand.
Now, if the truth is that you don’t have the budget to buy the necessary equipment to support your use case or the time/manpower to implement a Wireguard based solution that is understandable. What can be done with IPSec is much cheaper from a cost and support perspective compared to Wireguard currently. And although you mentioned Wireguard requires strong single-thread CPU performance (generic x86 CPUs from 2023+ are capable of 3-4GB/s out of the box without tuning), for great results you want a fast CPU but there are advancements such as Intel QAT Gen3 which greatly accelerates Wireguard and without the cost of “expensive” CPU compute (https://www.intel.com/content/www/us/en/content-details/764524/intel-qat-accelerate-wireguard-processing-with-4th-gen-intel-xeon-scalable-processor-technology-guide.html). At the end of the day it’s up to the operator to determine which path works best for their use case but saying Wireguard by default isn’t suitable for production needs that require high performance or maximum scalability is blatantly incorrect.
@blacksnow, OT – please start a separate thread on the subject. This one’s about ROS v7.19rc.
I really disagree with this one (within an RoS context). Let me explain:
Consider these Mikrotik routers:
hEX (https://mikrotik.com/product/RB750Gr3#fndtn-testresults)
hAP ac2 (https://mikrotik.com/product/hap_ac2#fndtn-testresults)
RB1100AHx4 (https://mikrotik.com/product/rb1100ahx4#fndtn-testresults)
CCR2004 (https://mikrotik.com/product/ccr2004_16g_2splus#fndtn-testresults)
CCR2116 (https://mikrotik.com/product/ccr2116_12g_4splus#fndtn-testresults)
Consider the info, here on forum, that hAP ac2 made about 700Mbps on Wireguard. And remember that Mikrotik table says it does 385,3 Mbps hardware IPSEC).
Now, answer me that: if (and only if) You agree with the statement that hAP ax2 made 700Mbps on Wireguard:
Would You agree that the RB5009 would fare FAR better than the stated 1409 Mbps 256 tunnels IPSec results?
Would You agree that one RB1100AHx4 would have a far worse result than the stated 1283,5Mbps IPSec results - comparing it to the RB5009 CPU?
Would You agree that the monster CCR2116 would fare something much higher than the 4104,4 Mbps (not even 3 times faster than the RB5009, with 4 times more cores, using a better CPU design)?
My point is this: “hardware acceleration” does wonders - but it doesn’t necessarily scales linearly with CPU capacity/core count. It’s quite common to implement it in a subset if circuits (GPUs do this, with video hardware encoding - they have ZERO relationship with GPU power), that have no direct relationship with the CPU itself.
SO
I agree with You that these “hardware implementations” do save CPU cycles. I don’t agree that they are always faster - because they are independent from CPU design, and have no bearing with its speed. We can do a slow IPSEC hardware implementation, and shove it in one really fast CPU. The same way Sun did a crappy floating point implementation, and shove it on their 16 core 64 thread monsters of the time. The SPARCs were really strange beasts…
Why is this relevant to us? Because it isn’t necessarily true that hardware IPSEC will be faster than software Wireguard. The answer is “it depends”.
Again, OT! Please start a separate thread and I’ll respond there, alright?
Anyway, just to spice up the debate before the new thread: 256 full-speed IPsec tunnels with almost no CPU impact equal, at most, 5–10 full-speed WireGuard tunnels with 100% CPU consumption on a CCR2216. And that’s a fact!
Just for information:
Ive found a bug concerning provisioning of local wifi interfacing using provisioning rules (dynamic enabled)
If you double provision or even triple provision local interfaces on an ax3 (might just be my ax3) the interfaces will enter an “unclear” state and refuse to work until a reboot.
Support is already working to resolve the issue.
This appears to be an issue since some beta version as i reported this issue before but it was less likely to appear so i closed the ticket.
You can’t complain about OT when I’m answering YOUR post!
And it isn’t with almost no CPU impact. I tested it with one hEX, and there is plenty of CPU impact. It gets the stated speeds, but the CPU get hammered all right. And yes, it was marked as “hardware offloaded”, before You ask. Tested it years ago, on RoS 6.x
Just pointing out that this "hardware accelerated “Y” is always faster than software accelerated “X” " isn’t necessarily true. It may very well be - but isn’t a given.
Hi @MikroTik
How we go with the VRF imelmatiations ? Still from the VRF1 we cant get access to the Main table.
VRF1 → VRF2…works
Main → VRF1…works
VRF1 → Main…does not works
It is located in a remote place and I can’t access it now, sorry.
7.19 has finally moved to RC? Great news!
now can we finally throw it in the bin and work on 7.20 where some actual improvements and features will make the pain worthwhile until stability is achieved