High bandwidth tunnels

This forum is for admins who are looking to build or expand their OpenVPN setup.
Forum rules
Please use the [oconf] BB tag for openvpn Configurations. See viewtopic.php?f=30&t=21589 for an example.
Post Reply
Skaperen
OpenVPN Power User
Posts: 76
Joined: Fri Aug 05, 2011 3:02 pm
Contact:

High bandwidth tunnels

Post by Skaperen » Mon Oct 30, 2017 5:00 am

i am assuming (but that could get me in trouble) that OpenVPN makes use of many CPUs and cores to speed up the encryption and decryption. is there any plans or suggestions to add the ability to make use of GPUs for even more cryptobandwidth?

User avatar
TinCanTech
OpenVPN Protagonist
Posts: 3347
Joined: Fri Jun 03, 2016 1:17 pm

Re: High bandwidth tunnels

Post by TinCanTech » Mon Oct 30, 2017 11:46 am

Openvpn is a single threaded process and I know of no plans to change this in OpenVPN 2.x
The only hardware acceleration I know of is done via OpenSSL -engine feature (eg. AES-NI)

Openvpn 3.x is in development and I have heard that it is multi-threaded but it is very bleeding edge.

Skaperen
OpenVPN Power User
Posts: 76
Joined: Fri Aug 05, 2011 3:02 pm
Contact:

Re: High bandwidth tunnels

Post by Skaperen » Tue Oct 31, 2017 6:00 am

good enough. i will be running many processes of OpenVPN in a few cases. i am putting together a tunnel scheme where the users don't need to deal with tunnel addresses ... for AWS users, to setup region to region tunnels, which could be as many as 13 processes per instance (if someone is using all 14 regions). it's in an AMI. just launch it in each region of interest and that instance finds all the others in the same AWS account and sets up the tunnel. when i ran it in all 14 regions myself, as a test, on a one core instance, it was slowing down rather significantly (one core divided up among 13 processes).

this scheme picks a random port for each tunnel, and exchanges that between regions along with keys. that way many tunnel endpoints can end in the same one instance.

maybe i can run two processes, one tunnel for each direction (different ports). that could at least be a win on 2 core instances. other tricks could involve dividing up traffic over many tunnels to have many processes using many cores for the more common cases of just 2 or 3 regions.

Post Reply