On Nov 19, 2017, at 6:08 AM, Victor Sudakov <v...@mpeks.tomsk.su> wrote:
> Muenz, Michael wrote: >>> >>> Is there any reason to prefer IPSec over OpenVPN for building VPNs >>> between FreeBSD hosts and routers (and others compatible with OpenVPN >>> like pfSense, OpenWRT etc)? >>> >>> I can see only advantages of OpenVPN (a single UDP port, a single >>> userland daemon, no kernel rebuild required, a standard PKI, an easy >>> way to push settings and routes to remote clients, nice monitoring >>> feature etc). But maybe there is some huge advantage of IPSec I've >>> skipped? >>> >> Hi, >> >> partners/customers with Cisco IOS or ASA wont be able to partner up >> without IPSEC. > > Sure, that's why I wrote "and others compatible with OpenVPN > like pfSense, OpenWRT etc" in the first paragraph. > > Jim Thompson wrote: >> >> Performance is better with IPsec. > > Because it's in the kernel? But many use (and recommend) StrongSwan > which is a userland implementation. Yes, because it’s in the kernel. OpenVPN uses tun/tap and there is considerable performance overhead due to multiple copies per packet across the user-space / kernel boundary using these. This problem is compounded by handing relatively small packets to OpenSSL’s EVP layer for encrypt/decrypt and authentication. Here is a write-up from 2011: https://homepages.staff.os3.nl/~delaat/rp/2010-2011/p09/report.pdf As you can read in the paper, the normal recommendation to overcome these is to increase the MTU on the TAP interface, and disable OpenVPV’s fragmentation routines. This serves to decrease these overheads. See also: https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux Note that this write-up is a bit duplicitous as they’ve disabled encryption and increased the “MTU” to reduce the per-packet copy overhead and eliminate the encryption overhead. More than once I’ve considered attempting to make OpenVPN work on top of netmap, just to see how much overhead could be negated via same. Use in a FreeBSD system would probably require VALE with a steering plugin to direct the OpenVPN frames to the OpenVPN processes, and the remainder to the kernel stack. On linux, one could use a SR-IOV VF with netmap and allow the rest of the NIC to be used for the system. Even with this, performance of OpenVPN will be constrained by the packet-at-a-time single thread of execution implementation inside OpenVPN’s code. While crypto can be offloaded, these can not. A rewrite will be needed to get to true 1gbps performance (or above). To address another of your arguments: StrongSwan does, indeed, have a user-land implementation of IPsec, most consumers (including pfSense) use StrongSwan for IKE/IKEv2 keying of an in-kernel (FreeBSD, Linux) IPsec implementation. Even StrongSwan’s primary author says the userland IPsec has performance issues. https://wiki.strongswan.org/projects/strongswan/wiki/Kernel-libipsec That said, we’ve benchmarked our userland IPsec implementation at 36.32 Gbps over 40 Gbps Ethernet with crypto offload via Intel’s QuickAssist, and yes, we use StrongSwan for IKEv2. The rest (40gbps - 36.32) is framing overhead. See slide 11: https://wiki.fd.io/images/1/1d/40_Gbps_IPsec_on_commodity_hardware.pdf. On slide 10 you can see that we obtained 13.7Gbps single-stream throughput using AES-GCM-128 and AES-NI. The next goal is to get to 100gbps using newer QAT cards and 100Gbps NICs. OpenVPN will never get close to these results without a rewrite. Nor, to address the elephant in the room, can it obtain the same performance as IPsec on FreeBSD today. >> It's a standard, too. > > IPsec in itself maybe a standard, but IKE does not seem to be much of a > standard, I get the impression that there's much incompatibility between > vendors (Cisco, racoon etc). RFC 4301, RFC 4303, etc all define IPsec proper. See section 1.3 of RFC 4301 for a more complete list. https://tools.ietf.org/html/rfc4301#section-1.3 RFC 7296 / STD 79 is the primary document for IKEv2. https://tools.ietf.org/html/rfc7296 Yes, there were implementation difficulties with ISAKMP/IKE (raccoon is IKE), but IKEv2 (Oct 2014) is considerably better when it comes to both security and interoperability of various implementations. Lessons were learned. OTOH, there is no RFC for OpenVPN, it’s a vendor implementation. Some documentation exists: https://openvpn.net/index.php/open-source/documentation/security-overview.html The other “VPN” that is getting increasing mention is “WireGuard” https://www.wireguard.com/. WireGuard’s performance page has additional comparisons between OpenVPN, IPsec and, of course, WireGuard. https://www.wireguard.com/performance/. These tests are on linux, not FreeBSD, because no port of WireGuard to FreeBSD exists. This said, more than one individual has expressed interest in a FreeBSD port of WireGuard. The main issue here is that WireGuard (like OpenVPN and StrongSwan) is GPLed, but unlike these two, a performant WireGuard implementation for FreeBSD would need to be in-kernel, and that’s not going to occur while the code is still GPL. The primary author of WireGuard has indicated a willingness to dual-license WireGuard’s code, so the potential exists. Jim _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
