CPU capable of doing gigabit OPENVPN?
-
So basically it isn't happening with any CPU worth using? On my gig connection through PIA, I get around 42 megabytes per second download. Through my ISP I get around 92-95. I guess that is manageable. I am using a Xeon D-1528 currently, but maybe bump to the 7700k. I tried the 7700K before, and it would not reboot PFSense for some reason. That was over a year ago so maybe the latest software will function well.
Thank you for your input :)
-
My input is more of food for thought than instructional. As for "So basically it isn't happening with any CPU worth using?", i'm not sure. I just used "500Mb/s/core" as a hypothetical value using roughly what you claimed to be getting in throughput. Mostly pointing out that while a single client may not be able to get gigabit rates, multiple clients in aggregate probably can, depending on how many cores you have and other hardware limitations.
I would not say I answered anything, but I did give some new perspective to hopefully help in your investigations.
-
requires a software 'fix' (rewrite).
it's on the schedule for TNSR (and SCLR).
-
Is there a CPU out there that can do OPENVPN at gigabit speeds? The highest end CPU at my disposal right now is a 7700K (which I am not using as a router). I have seen theoretical benchmarks of 256AES on that around 550mbps. So is there an actual CPU that can handle gigabit yet?
Thanks :)
None will. Also PIA does not allow you for more than 150/200 mbps per connection so the only way is to run multiple clients as a gateway group. This will help parallelisable load but won’t give you a single connection gigabit bandwidth.
-
I don't think that is entirely true. I am running 256AES PIA on my PFSense (I also have two connections to PIA for different subnets) and regularly get well over 500mb down. Normal cable directly in I get 980ish.
-
Multiple tunnels is the way to go though if you have multiple connections in the carried traffic. No single tunnel will ever be that quick.
Steve
-
Multiple tunnels is the way to go though if you have multiple connections in the carried traffic. No single tunnel will ever be that quick.
Steve
Is there a guide somewhere to setting up gateway grouping for exactly this: OpenVPN.
-
I wonder how the Ryzen CPUs would do with pfSense + encryption since Ryzen seems to have overkill encryption. I doubt it'll reach the 1Gbps mark but I'm curious how far they go
-
I wonder how the Ryzen CPUs would do with pfSense + encryption since Ryzen seems to have overkill encryption. I doubt it'll reach the 1Gbps mark but I'm curious how far they go
The bottleneck isn't the crypto–a skylake can AES-128-GCM more than 40 gigabits per second on a single core--the problem is elsewhere in the openvpn code, and throwing hardware at it has rapidly diminishing returns. I have not yet seen ryzen results with higher per-core throughput than intel, but I also haven't run a test myself and can't speak to the methodology. (They do seem to have high -ctr numbers, but that's basically a so-what until combined with a mac and also irrelevant for openvpn.)
-
Is there a guide somewhere to setting up gateway grouping for exactly this: OpenVPN.
Not really though it may be covered ion the advanced OpenVPN hangout we did a while back. Still in the archive for Gold members.
But it's pretty easy:
Create multiple clients preferably to multiple server instances. Each tunnel must have a different remote gateway in order to load balance correctly, just like a normal multiWAN scenario.
Set each client to not pull routes from the server as they will conflict.
Assign each of the client interfaces to get a gateway assigned.
Create a gateway group containing all the client gateways.
Policy route traffic from internal clients via that gateway group.
Steve
-
7700 should work fine. Ryzen or other AMD chips don't really help. Having a ton of 'extra' cores doesn't help either. If you have decent per-core speed and about 4 cores, that's about the best you can do at this time.
-
Is there a guide somewhere to setting up gateway grouping for exactly this: OpenVPN.
Not really though it may be covered ion the advanced OpenVPN hangout we did a while back. Still in the archive for Gold members.
But it's pretty easy:
Create multiple clients preferably to multiple server instances. Each tunnel must have a different remote gateway in order to load balance correctly, just like a normal multiWAN scenario.
Set each client to not pull routes from the server as they will conflict.
Assign each of the client interfaces to get a gateway assigned.
Create a gateway group containing all the client gateways.
Policy route traffic from internal clients via that gateway group.
Steve
I'm able to get traffic going through a PIA gateway group, but selecting 'Don't pull routes' for all of them appears to expose my actual IP on speedtest.net. I still have WAN selected as the default gateway, but have the PIA gateway group set as the gateway for my 'Allow LAN to any' rule at the bottom of my ruleset. Any suggestions?
-
If you are seeing your WAN IP theb it isn't routing via any VPN gateway. You should be able to see that in a traceroute for example.
If you are adding it to your 'allow all' rule you may not be clearing existing states between tests. Any open states via the WAN gateway will continue to pass traffic that way.
Steve
