Re: VPN recommendations?

[Mel Beckman <mel () beckman org>]

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 () gmail com<mailto:sneddon () 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 () cleverhack com<mailto:joy () 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 () zerotier com<mailto:joy.larkin () 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 () nanog org<mailto:nanog () nanog org>>
wrote:

You may try WireGuard and use ddns
From: NANOG <nanog-bounces+david=xtom.com () nanog org<mailto:nanog-bounces+david=xtom.com () nanog org>> On Behalf Of
William Herrin
Sent: Friday, February 11, 2022 2:02 AM
To: nanog () nanog org<mailto:nanog () 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 () herrin us<mailto:bill () herrin us>
https://bill.herrin.us/