3 ms·
> I'm yet to see a VPN product that can crack 200 Mbps even during periods of low load and with a matching gigabit link at the other end. WireGuard and IPsec (
by Fnoord 6y ago
> I'm yet to see a VPN product that can crack 200 Mbps even during periods of low load and with a matching gigabit link at the other end.
WireGuard and IPsec (the latter being a nightmare to set up) [1].
[1] https://camo.githubusercontent.com/907b408d818e9522afe5168c3f6014eb82773cb2/68747470733a2f2f7777772e636b6e2e696f2f696d616765732f7769726567756172645f636f6d7061726973696f6e732e706e67 https://camo.githubusercontent.com/907b408d818e9522afe5168c3...
- throwaway3neu94 6y agoThe protocol is not the problem here. Most commercial VPN products are IPsec internally, plus some proprietary authentication stuff. (So much that for several, there are open source reimplementations of just those parts, and the actual IPsec is done by the normal Linux kernel IPsec code. See OpenConnect's PulseSecure support for an example.) Also, having both run a VPN for a large network, and worked on VPN software for large networks, once you get to high user counts it's not as trivial as you think. VPNs introduce extra latency, probably the corporate VPN hub is not at all on the shortest path to your actual destination. And corporate VPNs tend to go through (multiple) layers of other filtering. The bottleneck can be Pkts/s, Byte/s or Connections/s and it is not at all obvious which it is. And so on. Besides, there are reasons corporations pay for expensive VPN solutions - certifications and compliance driven requirements such as integration of endpoint management. Not saying it can't be done, but "use IPsec or Wireguard" misses the point entirely. (Of course, if those products were using Wireguard instead of IPsec, it would probably help a bit.)