Date: Sun, 19 Nov 2017 19:02:42 -0600 From: Jim Thompson <jim@netgate.com> To: Victor Sudakov <vas@mpeks.tomsk.su> Cc: "Muenz, Michael" <m.muenz@spam-fetish.org>, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: OpenVPN vs IPSec Message-ID: <2472B38E-694E-4E3A-8234-DB231B532728@netgate.com> In-Reply-To: <20171119120832.GA82727@admin.sibptus.transneft.ru> References: <20171118165842.GA73810@admin.sibptus.transneft.ru> <b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org> <20171119120832.GA82727@admin.sibptus.transneft.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 19, 2017, at 6:08 AM, Victor Sudakov <vas@mpeks.tomsk.su> wrote: > Muenz, Michael wrote: >>>=20 >>> 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)? >>>=20 >>> 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? >>>=20 >> Hi, >>=20 >> partners/customers with Cisco IOS or ASA wont be able to partner up=20= >> without IPSEC. >=20 > Sure, that's why I wrote "and others compatible with OpenVPN > like pfSense, OpenWRT etc" in the first paragraph. >=20 > Jim Thompson wrote: >>=20 >> Performance is better with IPsec. >=20 > Because it's in the kernel? But many use (and recommend) StrongSwan > which is a userland implementation. Yes, because it=E2=80=99s 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=E2=80=99s 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=E2=80=99s 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=E2=80=99ve disabled = encryption and increased the =E2=80=9CMTU=E2=80=9D to reduce the = per-packet copy overhead and eliminate the encryption overhead.=20 More than once I=E2=80=99ve 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=E2=80=99s 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=E2=80=99s primary author says the = userland IPsec has performance issues. = https://wiki.strongswan.org/projects/strongswan/wiki/Kernel-libipsec That said, we=E2=80=99ve benchmarked our userland IPsec implementation = at 36.32 Gbps over 40 Gbps Ethernet with crypto offload via Intel=E2=80=99= 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.=20 >=20 > 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).=20 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=E2=80=99s a vendor = implementation. Some documentation exists: = https://openvpn.net/index.php/open-source/documentation/security-overview.= html The other =E2=80=9CVPN=E2=80=9D that is getting increasing mention is = =E2=80=9CWireGuard=E2=80=9D https://www.wireguard.com/. WireGuard=E2=80=99= 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=E2=80=99s not going to occur while the code is still GPL. The = primary author of WireGuard has indicated a willingness to dual-license = WireGuard=E2=80=99s code, so the potential exists. Jim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2472B38E-694E-4E3A-8234-DB231B532728>