Any chance you could send it to me (the compiled library). I would place it on my Vero4k+ and test it out there. Well, I’ll try it
Sam, I’m also interested in this, thanks!
I could be wrong but don’t think that will be enough.
I haven’t had much time to look into this, but it looks like the current openssl code (1.1.0f) can take advantage of the AES hardware extensions. I might well be wide of the mark here, but the problem now looks like openvpn isn’t currently able to use these AES extensions, since there appears to be no aes-ni type of kernel module for openvpn to call.
A quick look at the kernel compile options for 3.14.29-126 shows CONFIG_CRYPTO_AES=y
but I doubt if that’s enough to enable AES hardware acceleration.
Looking at /proc/crypto
we can see aes-generic compiled into the kernel but, again, there doesn’t seem to be evidence of it being hardware-accelerated.
Unfortunately, I won’t have much free time to look further into this for the next few weeks.
I would also be very interested. I’m on Vero 4K today using PIA and can get around 8-9MB/s on gigabit USB ethernet adapter. Just a data point for those wondering.
I’ve had a reasonably good look at this issue and it seems that the Vero4K (and, by extension, the Vero4K +) does use the ARM crypto extensions.
If you want to see how fast openvpn (and openssl) works without the extensions, prefix your command with OPENSSL_armcap=0
and you’ll see the difference. In terms of raw encryption power, one test suggested that it was a little under 2x faster with the extensions.
I don’t have a Vero4K + for testing but I’m able to push iperf3 on my Vero4K to around 90 Mbits/sec thtough a LAN-based openvpn tunnel and keep the Vero’s CPU running around 65% (with AES-128-CBC encryption). I’d therefore expect the Vero4K + to be able to push up to 130-150 Mbps, given its gigbit interface and higher clock speed, though much will depend on other factors, such the encryption algorithm used and what else is happening on the device.
If anyone wants to try some tests on a V4K+, I’ll be happy to show you a few.
I’d love to help progress this but my technical knowledge is extremely limited and I’d probably break something. I do hope there’s enough interest here to move some of this forward to a workable solution to speed vpn up.
I’d be interested. I have All Vero Devices here I could use for testing - also I have a 1Gbps FTTH at home, and my entire network is using Cat6 (double shielded) Cablings with a decent switch etc.
I really am able to push 940Mbps from and to the Vero 4K+ in my LAN.
Just give me some guidance, and I’ll give it a try
Iperf3 test
On V4K+:
cd /etc/openvpn
sudo -s
openvpn --genkey --secret ./static.key
You need to copy static.key
to /etc/openvpn on another device (assuming it’s *nix) that will act as the VPN server. It’s a character file so you can cat/copy/paste if you want. Then on /etc/openvpn create a client.conf
file:
remote <IP addr of server>
dev tun
ifconfig 10.8.0.2 10.8.0.1
secret static.key
cipher aes-128-cbc
auth sha1
To start it run openvpn --config client.conf >ovpn.log 2>&1 &
On the server side (assuming static.key has been copied over):
cd /etc/openvpn
sudo -s
chmod 600 static.key # this should stop openvpn complaining
create server.conf file:
dev tun
ifconfig 10.8.0.1 10.8.0.2
secret static.key
cipher aes-128-cbc
auth sha1
then start it: openvpn --config server.conf >ovpn.log 2>&1 &
then run iperf3 -s
Back on the V4K+ check the ovpn.log to see if the Initialization Complete message has appeared, then run
iperf3 -c 10.8.0.1 -t 60
(Note that we’re forcing traffic through the VPN tunnel by using IP address 10.8.0.1. You can bypass the tunnel by using its real IP address, assuming the V4K and server are on the same subnet.) In a separate SSH session, it would be worth running top to see how much CPU is being used. Ideally, Kodi should be switched off for the tests.
As already mentioned, to switch off (all of) the ARM crypto extensions, you need to prefix the command with OPENSSL_armcap=0
, eg:
OPENSSL_armcap=0 openvpn --config client.conf >ovpn.log 2>&1 &
(AFAICT, bit position 0 (LSB) of OPENSSL_armcap controls onboard AES encryption, position 2 controls SHA1 hashing and position 3 controls SHA256 hashing, openssl/armcap.c at master · openssl/openssl · GitHub so you can switch them on and off individually.)
The above test uses AES-128-CBC encryption with a SHA1 HMAC. If you feel so inclined, you can test other ciphers and authentication hashes. (Specify none
for no cipher or auth.)
I came across another test that measures raw encryption/decryption power - and doesn’t use the network at all. Again, while in /etc/openvpn, run:
time openvpn --test-crypto --secret ./static.key --verb 0 --tun-mtu 20000 --cipher aes-128-cbc
and with disabled crypto extensions:
time OPENSSL_armcap=0 openvpn --test-crypto --secret ./static.key --verb 0 --tun-mtu 20000 --cipher aes-128-cbc
To get a rough approximation of the maximum openvpn throughput, divide 3200 by the total elapsed time in seconds. The projected speed should be an upper limit under optimum conditions.
The magic number of 3200 comes from summing 1 to 20000, multiply by 2 for encrypt and decrypt and by 8 bits/byte and divide by 1,000,000 for a result of Mbps
So - according to your tests as proposed:
root@vero4k2:/etc/openvpn# time openvpn --test-crypto --secret ./static.key --verb 0 --tun-mtu 20000 --cipher aes-128-cbc
Tue Nov 27 09:28:30 2018 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
real 0m20.052s
user 0m19.950s
sys 0m0.040s
root@vero4k2:/etc/openvpn# time OPENSSL_armcap=0 openvpn --test-crypto --secret ./static.key --verb 0 --tun-mtu 20000 --cipher aes-128-cbc
Tue Nov 27 09:29:41 2018 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
real 0m38.197s
user 0m38.050s
sys 0m0.000sindent preformatted text by 4 spaces
With the aes engine on: 3200/20.052 = 159.58Mbps
Without aes engine: 3200/38.197 = 83.77Mbps
Note that CPU is at 100% here…
So, a almost 100% speed increase with the current setup.
On my Vero4K, I was getting times of around 19.9 seconds with the crypto extensions enabled and around 37.6 seconds with them disabled - so slightly faster then you, which is a bit of a surprise. Can you confirm that this is on a Vero4K + and that Kodi has been disabled.
It’s not using the network interface, so this is to be expected. You need to run the iperf3 test for a more real-world idea of its performance over a network.
Ok. I can confirm this is on a Vero4k+, but Kodi was running.
root@vero4k2:/etc/openvpn# time openvpn --test-crypto --secret ./static.key --verb 0 --tun-mtu 20000 --cipher aes-128-cbc
Tue Nov 27 21:14:09 2018 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
real 0m19.905s
user 0m19.860s
sys 0m0.020s
root@vero4k2:/etc/openvpn# time OPENSSL_armcap=0 openvpn --test-crypto --secret ./static.key --verb 0 --tun-mtu 20000 --cipher aes-128-cbc
Tue Nov 27 21:14:46 2018 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
real 0m37.794s
user 0m37.680s
sys 0m0.070s
This is with Kodi disabled.
3200/19.905=160.76Mbps
3200/37.794=84.66Mbps
Regarding the speed difference, I don’t think there was much to be expected. The Vero 4K and 4K+ are using the same CPU if memory serves me well.
Regarding the network side stuff, my J1900 Atom System based firewall is able to handle around 150Mbps VPN traffic in AES-256-cbc. But I don’t know if it is due to the Tablet I make my tests (Google Pixel C) with, or the limitation of the internet connections from the outside.
Reconfiguring my firewall (All handmade) to access VPN connections from the inside will take a while.
The ARM is running at the same clock speeds; yes.
The memory is faster in the 4K +; but I don’t think that’s the bottleneck here.
Did you manage to reconfigure your firewall and run the tests?
Sorry, no. I’m on travel the last weeks and scheduled until Christmas. I don’t know if I then will have time to do it as I have to upgade my server and firewall (running on ubuntu 14 LTS adn 16 LTS) and take care of the family.
Fair enough. Perhaps someone else with a Vero4K + and suitable infrastructure would like to test the iperf3 speed over OpenVPN, with and without hardware acceleration. Details above.
To throw a spanner in the works: what do you guys think about Wireguard? It looks like a new, and simpler way, to do VPN.
I really like the concept. It is clean, and the best thing, it is resilient on IP address changes. Amazing.
This is what was required for a long time now.
The fact that each client traffic is authentication/verified makes it really secure. Hadn’t seen that so far. Thx for pointing it out.
I think the hardest will be to add a decent configuration UI
A security product needs to be well-tested, robust and, of course, secure. For most people, it will be used as a way of connecting to a commercial VPN server, so its take-up will depend on how keen VPN providers are to dive into a bleeding-edge product.
I’m also a little concerned that it runs as a kernel module, rather than in user space.
I’ll certainly experiment with it once it gets past version 0.0.x but it’s still very early days.
Yes – I think support went in to a very recent 4.18 or 4.19 kernel; so it will likely be a long time before it’s usable and trickles down to vendor kernels.
It will likely need to see its way in an LTS kernel to gain some traction.
I hear you here.
But keep in mind that the idea is for it to be simple code and easy readable in contrary to the large code bases of other VPN software. That is the point of it. KISS. The simpler the concept, the easier the implementation. I see it as a VPN system using similar techniques as ssh. And everyone uses ssh nowadays.