What speeds could we achieve using the router as OpenVPN client?

Turris Omnia
1

Hi,

I recently bought a router that can’t only provide to my devices more than 10Mbps download / 16 Mbps upload speed when it’s used as OpenVPN client.

I googled a lot and I could see that apparently most of the rotuers struggle to provide speeds higher than 20Mbps download / 16Mbps upload when the router is the OpenVPN client but someone informed me that the Turris Omnia maybe could.

Does anyone know (has it been tested by the devs) which speed could deliver the Turris Omnia if it’s used as OpenVPN client with openwrt?

Thank you,

2

They’ve mentioned in an update that they were able to reach 100Mbps, but bear in mind that the router is expected to perform other tasks as well and only has 2 core, ones of which is maxed out by OpenVPN (this could change with hardware acceleration, if they can make it work).

We’re all waiting for more numbers, but it will depend on your upstream connection and your expectations. There is only 1GB of RAM on these devices.

3

100 Mbit, that would be awesome. I always thought this was just a CPU issue, does memory really play a role here as well? Then I should probably consider the 2GB upgrade. Let’s hope for some generous and efficient passive cooling and the potential to even OC the device to 1.8 eventually. I might have to get a box like this.

4

@ titooo7, the current dual-core ARM routers with >1GHZ can do much more VPN throughput. 35-50 Mbit/s depending on config with the Netgear R7000 or Asus AC68U, with Tomato, DD-WRT or Merlin.

5

My comment about memory was more about the fact that you will be tempted to run other software on the same device and that you may run out of memory before you run out of CPU cycles. Now with the 2GB upgrade, you would definitely have enough to install some cool graphing, filtering or traffic shaping apps.

And since there are only 2 cores, I think it will really help if we can limit the bandwidth used by the tunnels we create.

6

One thing to bear in mind… There was no information given about the ciphers used.
Since the results are in line with what you can achieve with a WRT1900ACS (same SoC), I suspect Blowfish-CBC was used for testing. With AES128-CBC you get a minimum of 20% performance hit, so that would be 80Mbit, still very good.
The results also depend on if you’re connecting to an endpoint your own (and can configure/tune) or if you’re connecting to an off the shelf VPN service.

7

But I’m guessing that when those tests are done it would be good to know not only the cipher used (as you mentioned in one of your latest posts) but also if the router is being used as openvpn router or client.

I guess that the speeds that it reach could be different depending on if the router is the openvpn or client. Am I wrong?

8 
00000000  43 6f 72 72 65 63 74 2e  20 20 20 20 20 20 20 20  |Correct.        |
00000010  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 0a  |               .|
00000020
9

The comment page on igg says that they are testing drivers for hardware AES acceleration. If that works well, then the VPN throughput should go up a fair bit.

10

Let’s hope so. AES-NI on x86 does almost nothing for OpenVPN per example (it does for IPSec), but CESA supports CBC, so there is hope.

11

IPsec also uses CBC mode so there should be no big difference in IPsec vs OpenVPN except when using in-Kernel-IPsec and Kernel supports AES-NI but OpenSSL does not support AES-NI.

Still waiting for benchmarks of CESA as this was about the same speed as CPU-only on Kirkwood with Linux. Under FreeBSD it was really faster though. May have changed by now.

12

How does that happen?

And I think that what we’ll see is that there will be almost no difference in throughput, but the CPU will be free for other tasks. The only problem is that the 100Mbit limit will be shared amongst all connections, where as with a software only solution on a quad-core Celeron, you can open a couple of 100Mbit connections, but I don’t expect many backers to run that scenario.

13

The Linux Kernel has its own crypto function. These may be available to userspace via AF_ALG or /dev/crypto if this is enabled and /dev/crypto may even need a patch.

OpenSSL has its own support for AES-NI and may be built without it. There even seem to be 2 different implementations:

  • as openssl engine (pre 1.0.1)
  • automatic when using EVP_-functions (1.0.1)
    The latter may be a problem with older OpenVPN. The AES-NI-changes in OpenSSL seem to also speedup non-AES-NI-operation so this may be the part on being faster.

The problem with speed on Kirkwood was moving data between user-space and kernel-space and back for encryption. OpenSSL gives data to Kernel, Kernel gives data to CESA, and all the way back together with all the context switches etc.

1 Like
14

According to my testing, the max throughput for AES-256-CBC is currently around 80mbit/s (openvpn reaches 47-50% CPU at that point, meaning that it is indeed the ceiling, since it is single-threaded).

For more one could run two tunnels and load balance them.

1 Like