I've been asked to recommend new router for office. Being big RouterOS fan, I had no doubt, let's get some nice RouterBoard! Requirements are ability to handle ~50/50Mbit connection (that should be easy) and also the role of VPN server (probably OpenVPN or SSTP) with good speed. The other requirement turned out to be not so easy.

I don't know if it's just me, but I can't find decent info anywhere. It's just mostly random report here and there, but nothing comprehensive where potential buyer could easily compare available models.

Some info I was able to find could be called disturbing. Like RB3011 having some hw acceleration, but still not supported by sw, even though the router was released almost two years ago. Will it ever happen? At least it should be able to handle over 70Mbit in software, if I remember the report correctly, so it could do.

Other info seems to be incomplete. For example RB1100AHx2 or RB750Gr3 should handle several hundereds Mbits, that sounds great. But with that info being only on IPSec page, can I hope for it to apply to other VPNs too, or am I too optimistic? It would be nice to be sure before buying anything.

I guess any CCR should be safe bet (although I didn't find too much info either), but it's rather smallish office, so they may think it's too expensive.

Did I just miss something? Or is there a huge space for improvement here? I can't be the only one wondering about these things...

Hello.

I found a time ago this articule, i think it can help you

http://rickfreyconsulting.com/mikrotik-vpns/

Is from Rick Frey

Thanks, I found that page too, but it compares different protocols and not different devices, there's only one CRS model used for tests. Also that IPSec performance is hard to believe, because AFAIK no CRS has any hw acceleration (product page definitely doesn't say anything about it).

If there only was some "buyer's guide" from MikroTik...

I think MikroTik people is very cautious to make a "buyer's guide" cause there are to many combination of situations inside RouterBoard hardware.

I will be useful something like a matrix of routerboard capabilities.

Hello.

I found a time ago this articule, i think it can help you

http://rickfreyconsulting.com/mikrotik-vpns/

Is from Rick Frey

This article is useless because it uses a "switch with some routing functionality" that is not at all suited for VPN usage.
Also, the author compares VPN speeds (which are capped by CPU performance) to line speed (a very high line speed in
his case) to compute "percentage loss due to VPN". I call it clueless.

I've been asked to recommend new router for office. Being big RouterOS fan, I had no doubt, let's get some nice RouterBoard! Requirements are ability to handle ~50/50Mbit connection (that should be easy) and also the role of VPN server (probably OpenVPN or SSTP) with good speed.

Well when you want good speed you should not be restricted to dumb solutions like OpenVPN over TCP or SSTP.
Of course there often is the desire to connect from unmanaged devices setup by the home user, which makes it hard to do things like IPsec.
However, L2TP/IPsec is usually possible with the typical client OS run at home.

I have good results with the RB750Gr3 for L2TP/IPsec and GRE/IPsec also in combination with a CCR1009.
Beware that the CCR reorders packets which does not work well with Windows. With Linux I see no issues.
50/50 should be easily achievable with even the cheap RB750Gr3. I like the CCR1009 for its redundant powersupplies and fans.

I don't think it's fair to call OpenVPN or SSTP dumb...depending on the environment, some organizations block just about everything outbound except TCP ports 80 and 443. In such situations, things like OpenVPN and SSTP are the only options, as they're the least likely to get block by outbound filtering. Sure, they're slower than UDP based protocols, but if those protocols are being block, even a slow VPN solution is better than one that won't work.

I call them dumb because they are slower and are prone to congestion collapse.
I know that some people have no other solutions but that does not suddenly make them perform better.

They're slower because they use TCP instead of UDP, which is what gets them by firewalls...making them a pretty smart choice. As for congestion collapse...I've never had my SSTP tunnel collapse on me, but given that all the encryption is currently done in software, it's not hard to peg a CPU with a very low amount of traffic, resulting in a collapse due to resource exhaustion.

Bottom line: they're not dumb, just intended for specific use cases where other VPN options simply aren't viable.

I've never had my SSTP tunnel collapse on me, but given that all the encryption is currently done in software, it's not hard to peg a CPU with a very low amount of traffic, resulting in a collapse due to resource exhaustion.

Just Google and read what TCP over TCP meltdown problem is. It's not in any way related to resource exhaustion. I agree that in some paranoid situation tunneling VPN traffic over HTTPS may be the only option, however in other situations you should avoid VPNs that use TCP as a transport.

As for congestion collapse...I've never had my SSTP tunnel collapse on me, but given that all the encryption is currently done in software, it's not hard to peg a CPU with a very low amount of traffic, resulting in a collapse due to resource exhaustion.

That is not what congestion collapse is. It is the situation where a small and saturated link (e.g. a mobile network) becomes completely overloaded because users are re-transmitting packets faster than the network can transport them, and therefore they never get any real data transferred at all.
This is normally avoided by a sensible TCP implementation (exponential backoff of re-transmit timer, watching out-of-sequence packets and acks and throttling down when they are observed),
however in a TCP based VPN there are to NESTED TCP sessions that both do their own retransmission.
This means that when the network is slow, it is hammered extra hard.
This has nothing to to with CPU usage.

SSTP and alikes usage quite generic and common thing.
as for overhead - ANY implementation of - add considerable amount of.
and since ROS didn't support UDP version of OpenVPN nothing to argue about(eg compare with).

Ok, point taken, IPSec VPN good, TCP-based VPNs bad. Well, why not, there can be two VPNs, primary fast one (IPSec) and backup compatible one (SSTP/OpenVPN) and everyone can be happy.

So if a device with hw acceleration is used, then it's enough to select right algorithms and IPSec speed can't be a problem, no matter what other IPSec settings are used, right?

Stupid question, acceleration being supported only for IPSec, is that a technical thing or just decision made by MikroTik? I thought that it was like AES-NI on x86 processors. Not that I have deep knowledge of that, but AFAIK it's just a bunch of generic instructions for making AES encryption faster and any program can use them (not without help from its developer of course). So in theory, could encryption for all VPNs in RouterOS be accelerated?

Back to the point of my post, it would still be nice to have some official numbers. Let's say I want to get RB750Gr3, because given the capabilities and price, it looks like great device. In case IPSec can't be always used, it would be nice to know what can be expected from other kinds of VPN. It can hardly cover every possible config, but at least something for orientation ("SSTP with AES128 can do at most X Mbit/s"). Or if I wanted to get a different RB for some reason, e.g. RB3011, because I'd need more ports, how can I know what to expect? I did find some info that can be called official, but it still belongs to "random report here and there" category.

Stupid question, acceleration being supported only for IPSec, is that a technical thing or just decision made by MikroTik?

I think it's more likely to be technical, rather then political. IPsec is a two-phase protocol, with phase 1 (connection negotiation) being done mostly in userland, while phase 2 (the actual traffic processing/encryption) is done fully in kernel (with the only exception being NAT-T, where the already encrypted ESP packets are passed from kernel to userland to be encapsulated and sent out via UDP). My understanding is that hardware-accelerated encryption is likely to be only supported in-kernel as of now, and thus it is only phase 2 that supports hardware accelerations. Other VPN protocols are handled mostly in userland, and that what makes them different from IPsec. Adding hw-accelerated encryption for, say, OpenVPN or SSTP is definitely possible, but that's possibly a substantial amount of work that is yet to be done.

Ok, point taken, IPSec VPN good, TCP-based VPNs bad. Well, why not, there can be two VPNs, primary fast one (IPSec) and backup compatible one (SSTP/OpenVPN) and everyone can be happy.

Standard OpenVPN can also operate over UDP but unfortunately the OpenVPN in RouterOS is not the standard one (now it is finally explained why it is lacking so many of the useful features) and it only does TCP.
Other VPN technologies that can be used are L2TP (works over UDP) and PPTP (works over GRE which is a datagram protocol alongside of TCP and UDP, can often work OK but some NAT routers won't transport it).

Well, I've personally used almost everything over the years. First one was CIPE, non-standard UDP-based site-to-site tunnel, that was great, simple and reliable. It was later replaced by OpenVPN, because at the time I found it much more user-friendly than IPSec. Now IPSec and I are friends for static site-to-site use, no problems there. But not for road warrior use, I still didn't get over past experiences with it, when it was PITA to configure and debug. The truth is, I didn't really try lately, because OpenVPN was working great (mostly original with UDP, only few little used ones on RouterOS with TCP). PPTP was synonym for NAT troubles from beginning. And L2TP needs IPSec, so it was out too. SSTP is good for "I don't want to install anything, just give me username and password" types of users, plus it doesn't have any problems with firewalls, that helps too.

Time to get friendly with all kinds of IPSec, I guess.

And L2TP needs IPSec, so it was out too.

That isn't true. It can be used without IPsec but that is often considered "insecure" by security maniacs, just like PPTP.
In Windows, configuring an L2TP connection actually makes a L2TP/IPsec connection by default (I think it can be changed only by tweaking the registry)
so for practical purposes you could think "it needs IPsec", but e.g. between MikroTik routers this is not true.