VPN recommendations?

Fri Feb 11 18:47:25 UTC 2022

Dan,

One point you didn’t touch on is that IPSec is integrated into IPv6, typically hardware-accelerated on the NIC, enabling device-to-device VPNs, mitigates most of the dynamic issues associated with network-to-network IPSec over IPv4.

Yes, I realize IPv4 is hanging around longer than most expect, but in some cases I think you can make a case for deploying IPv6 just on the VPN benefits alone. With no public-facing services, IPv6 is already deployed in most LANs as a direct result of its use by modern OSes for inter-LAN communication. All you typically need to do is enable IPv6 at the gateway.

 -mel

On Feb 11, 2022, at 10:33 AM, Dan Sneddon <sneddon at gmail.com<mailto:sneddon at gmail.com>> wrote:

Thank you Joy for de-lurking. I actually was not familiar with ZeroTier, and this is a space that I thought I was quite familiar with, so I’m glad you brought it to everyone’s attention. I will look further at ZeroTier, it looks very interesting.

I am also a very long-time lurker (although I was a NANOG list admin ~10 years ago) who is emerging to join this conversation.

I have recently been doing some work to evaluate and develop VPN solutions for connecting multiple data center cloud environments, including low-power small edge sites, and I have some thoughts about the current state of the art to share.

Until recently a very strong proponent of IPSEC. I liked the way IPSEC was placed within the OSI model directly at layer 3, unlike some of the VPN technologies which operate above or below layer 3. However I do not believe that IPSEC is future-proof, for the following two reasons:

1) IPSEC does not lend itself to dynamic routing or dynamic configuration. It is very much a static set-it-and-forget-it technology, but that doesn’t work in a dynamically changing environment.

2) IPSEC does not always lend itself to hardware offloading in the way some other technologies do. Some NICs do support hardware acceleration for IPSEC, but this does not always integrate well with kernel or user space when you are integrating virtual network functions (VNFs) like routers/firewalls/load-balancers.

Wireguard works well in dynamic environments. TLS using something like OpenSSL does as well. Both provide key advantages, particularly on top of Linux.

* Support for hardware offloads such as TCP segmentation provide vast improvements in performance on higher-end x86 hardware. Some recent testing I have been shown proves that TCP segmentation offload can provide more than a 5X speedup compared to other HW offloads without TCP segmentation (from 5Gb/s to above 25Gb/s in some tests).

* With the right encryption algorithm CPU acceleration for cryptography reduces CPU load and increases performance.

* Integration with kernel routing provides the ability to integrate with dynamic routing such as BGP daemons (e.g. FRRouting, etc.).

* In recent Linux kernels eBPF/XDP provide a hardware interface to the kernel which accelerates network throughput to near line-rate, while minimizing CPU impact.

This may not apply to William Herrin’s (OP) use case of a VPN appliance for 100mbps to 1gbps speeds, but it is something to keep in mind for building higher performance solutions or for planning for increasing bandwidth in the future. For the 100mbps+ use case I have had success building appliances using OpenVPN on top of certain ARM based platforms like Marvell Armada, or single-board computers with Intel CPUs with AES-NI acceleration. I am currently looking at implementing Wireguard on the same platforms. For a simple low-power ARM router appliance the Turris Omnia has been a great fully open platform running a custom LEDE/OpenWRT OS. The Turris Mox provides a modular hardware platform for expandability, albeit with slightly less performance. Both of these platforms are developed by the engineers at CZ.nic, the TLD registrar for the Czech Republic.

https://secure.nic.cz/files/Turris-web/Omnia/Omnia2020_datasheet.pdf

https://www.turris.com/en/mox/overview/

-Dan Sneddon

On Feb 10, 2022, at 10:51 AM, joy at cleverhack.com<mailto:joy at cleverhack.com> wrote:

Hello NANOG,

My name is Joy Larkin and I'm actually a long-time years-long lurker on the NANOG list (I have v odd hobbies) and I am also ZeroTier's Head of Marketing. I know I'm not supposed to be too promotional on here, but I'd love to see some of you pick up ZT.

Our founder, Adam Ierymenko just did a talk at Networking Field Day 27, here are two of the recordings from that session:

* ZeroTier The Planetary Data Center
   * https://www.youtube.com/watch?v=T2BbrqpnMAE

* ZeroTier Technical Deep Dive
   * https://www.youtube.com/watch?v=VhQ30bVF3_s

If you have questions, let me know - you can reach me at joy.larkin at zerotier.com<mailto:joy.larkin at zerotier.com>

Best,
-Joy

On 2022-02-10 10:12, Mike Lyon wrote:
How about running ZeroTier on those Linux boxes and call it a day?
https://www.zerotier.com/
-Mike
On Feb 10, 2022, at 10:07, David Guo via NANOG <nanog at nanog.org<mailto:nanog at nanog.org>>
wrote:

You may try WireGuard and use ddns
From: NANOG <nanog-bounces+david=xtom.com at nanog.org<mailto:nanog-bounces+david=xtom.com at nanog.org>> On Behalf Of
William Herrin
Sent: Friday, February 11, 2022 2:02 AM
To: nanog at nanog.org<mailto:nanog at nanog.org>
Subject: VPN recommendations?
Hi folks,
Do you have any recommendations for VPN appliances? Specifically: I
need to build a site to site VPNs at speeds between 100mpbs and 1
gbit where all but one of the sites are behind an IPv4 NAT gateway
with dynamic public IP addresses.
Normally I'd throw OpenVPN on a couple of Linux boxes and be happy
but my customer insists on a network appliance. Site to site VPNs
using IPSec and static IP addresses on the plaintext side are a dime
a dozen but traversing NAT and dynamic IP addresses (and
automatically re-establishing when the service goes out and comes
back up with different addresses) is a hard requirement.
Thanks in advance,
Bill Herrin
--
William Herrin
bill at herrin.us<mailto:bill at herrin.us>
https://bill.herrin.us/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220211/55268120/attachment.html>