High bandwidth tunnels
Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech
Forum rules
Please use the [oconf] BB tag for openvpn Configurations. See viewtopic.php?f=30&t=21589 for an example.
Please use the [oconf] BB tag for openvpn Configurations. See viewtopic.php?f=30&t=21589 for an example.
-
- OpenVPN Power User
- Posts: 89
- Joined: Fri Aug 05, 2011 3:02 pm
- Contact:
High bandwidth tunnels
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?
-
- OpenVPN Protagonist
- Posts: 11137
- Joined: Fri Jun 03, 2016 1:17 pm
Re: High bandwidth tunnels
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.
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.
-
- OpenVPN Power User
- Posts: 89
- Joined: Fri Aug 05, 2011 3:02 pm
- Contact:
Re: High bandwidth tunnels
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.
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.