Re: [strongSwan] Maximizing throughput / kernel bottlenecks
(one of which is quite old - running a dual core netburst P4 @2.8, the other two are VMs on decent hardware, all of which have no load) are hitting walls at 300mb/s On a Netburst architecture you can't expect more; it does not have any acceleration for AES-GCM. but can hit 980mb/s unencrypted, leads me to some kind of kernel bottlneck. Encryption is that expensive. The two VMs have aesni support, or at least the aesni extension is getting passed through the hypervisor to them. AESNI is half of the story only, you'll need CLMUL instructions as well (pclmulqdq in /proc/cpuinfo). Try to run modprobe tcrypt sec=1 type=4 mode=211 and check dmesg for the benchmark results. Unfortunately no one seems to have any concrete information (asked about this previously). My testing shows that there's a bottleneck somewhere between 200-300mb/s most likely in the kernel somewhere That's not true. Saturating Gbit links is not much of a problem with AESNI/CLMUL accelerated AES-GCM. Even with the AVX2-enabled ChaCha20Poly1305 I got 700MBit/s on a single core, without pcrypt. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Maximizing throughput / kernel bottlenecks
What you say...Martin Willi (mar...@strongswan.org): > Hi, > > > There is no appreaciable load on any of the systems > > during throughput testing. > > Please note that IPsec is usually processed in soft IRQ, so have a look > at the "si" field in top. If you are CPU bound, "perf" is very powerful > in analyzing the bottleneck on productive systems. If you are not CPU > bound, something else is probably wrong (packet loss, etc.). I'll have to look into perf; my si stat isn't really going that high. Its maximum is 13.4. That doesn't seem excessive, though it's not great. > > I've read that aes-gcm has been built to scale to 10ge and 40ge, > > It has, but saturating such links definitely requires hardware support. > > > Does anyone else have experience with higher throughput on > > their IPsec tunnels, whether or not utilizing aes-gcm? > > If your CPU has AESNI/CLMUL support, depending on your CPU you should > at least get close to saturating a Gigabit link, even if using a single > core only. > > If you have multiple tunnels, a NIC with multiple hardware queues can > share the load to more cores; if not pcrypt is an option. > > With traditional algorithms you should achieve around 200-400Mbit, so > you should go for AES-GCM if your hardware supports it (make sure to > have rfc4106-gcm-aesni in /proc/crypto). Alternatively, you might give > the newer chacha20poly1305 AEAD a try; it provides good performance in > software, and even better performance with SSE2/AVX2 (since Linux 4.3). > > Regards > Martin I did switch to aes-gcm, though didn't get any performance benefit out of it. So that, plus the fact that between three systems with tunnels between them (one of which is quite old - running a dual core netburst P4 @2.8, the other two are VMs on decent hardware, all of which have no load) are hitting walls at 300mb/s but can hit 980mb/s unencrypted, leads me to some kind of kernel bottlneck. The two VMs have aesni support, or at least the aesni extension is getting passed through the hypervisor to them. I do have access to very beefy hardware that I could run baremetal, but I'd like to only use that as last resort for testing. At this point I'd love to have a working 700mb/s+ tunnel so I could use it to troubleshoot the other tunnels / hardware. I feel like a bog standard VM with no resource contention and no local load would be able to push at least 500mb/s without too much tweaking. hose ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Hardware for 1gbp/s
Hmm. As a random datapoint, we routinely sustain 450Mbps+ on instances in Amazon using a Centos 6.7 image on a c3.large instance type 2 cores : CPU0: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz stepping 04 4GB of RAM We do NAT-T which pushes it to udp/4500 and we tweaked the buffers there. Haven’t played too much more with it because that was sufficient for us, but you can sustain almost half a gig on a lightweight instance. EKG > On Apr 11, 2016, at 1:34 PM, Hose wrote: > > What you say...Fred (curious_fre...@gmsl.co.uk): > >> >> What kind of hardware is required to maintain a point to point ipsec link >> with 1gbp/s b/w with Strongswan at each end. >> >> Are there any things/overheads to be aware of from the Strongswan side of >> things? Performance degradation, lower throughput etc as a result of running >> the actual crypto. >> >> Fred. > > Good luck with this. Unfortunately no one seems to have any concrete > information (asked about this previously). My testing shows that there's > a bottleneck somewhere between 200-300mb/s most likely in the kernel > somewhere, as throwing more cores and attempting to parallelize it > improves nothing. Those things may help with multiple IPsec tunnels, but > a single tunnel doesn't show any improvement. > > This was on Debian 8.3 with various kernels in there > ranging from 3.2 to 3.16; a newer kernel may help, but that's just > speculation. > > hose > ___ > Users mailing list > Users@lists.strongswan.org > https://lists.strongswan.org/mailman/listinfo/users smime.p7s Description: S/MIME cryptographic signature ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] dhcp plugin: how to verify dhcp options forwarded to road warrior?
On 04/11/16 16:24, Harald Dunkel wrote: > Hi folks, > > Using IKEv2 to connect to MacOS 10.11.4: > PS: Sorry, this was misleading. Its a road warrior scenario between a few MacOS laptops and a central strongswan installation using IKEv2. The connections are initiated only by the laptops. Strongswan uses the dhcp plugin to obtain an IP address and DNS information. > It seems that either the received DHCP options are not forwarded > to the MacOS client, or the MacOS client ignores these options. > Charon's log file entries show the DHCP discover and the received > IP address and netmask, but it doesn't show which options are > sent to the road warrior, and if this information is accepted > or rejected. > > How can I verify? There are plenty of DNS related options in > strongswan 5.3.4. Which options do I *really* have to set to > make at least full DNS over IPsec work with MacOS? > > > Every helpful comment is highly appreciated. > Harri Sorry for the confusion Harri ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Hardware for 1gbp/s
What you say...Fred (curious_fre...@gmsl.co.uk): > > What kind of hardware is required to maintain a point to point ipsec link > with 1gbp/s b/w with Strongswan at each end. > > Are there any things/overheads to be aware of from the Strongswan side of > things? Performance degradation, lower throughput etc as a result of running > the actual crypto. > > Fred. Good luck with this. Unfortunately no one seems to have any concrete information (asked about this previously). My testing shows that there's a bottleneck somewhere between 200-300mb/s most likely in the kernel somewhere, as throwing more cores and attempting to parallelize it improves nothing. Those things may help with multiple IPsec tunnels, but a single tunnel doesn't show any improvement. This was on Debian 8.3 with various kernels in there ranging from 3.2 to 3.16; a newer kernel may help, but that's just speculation. hose ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] dhcp plugin: how to verify dhcp options forwarded to road warrior?
Hi folks, Using IKEv2 to connect to MacOS 10.11.4: It seems that either the received DHCP options are not forwarded to the MacOS client, or the MacOS client ignores these options. Charon's log file entries show the DHCP discover and the received IP address and netmask, but it doesn't show which options are sent to the road warrior, and if this information is accepted or rejected. How can I verify? There are plenty of DNS related options in strongswan 5.3.4. Which options do I *really* have to set to make at least full DNS over IPsec work with MacOS? Every helpful comment is highly appreciated. Harri ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Good information on adding custom ESP encryption
Martin, Thank you very much for these links and the information. I have found them very useful and they will make a great example on how to do this. I appreciate it. Regards, ~Josiah s. Yeagley -Original Message- From: Martin Willi [mailto:mar...@strongswan.org] Sent: Saturday, April 09, 2016 4:15 AM To: Yeagley, Josiah (U.S. Person) Cc: users@lists.strongswan.org Subject: Re: [strongSwan] Good information on adding custom ESP encryption Hi, > I believe the only real way to do this is via a kernel module using > the CrytpoAPI. It then has to be registered with the OS and > strongStwan and can then be used by specifying esp= Yes, that is correct. For an example you may take a look at the patchset that implements the ChaCha20Poly1305 algorithm [1]. It exposes an AEAD to IPsec, but the mechanics are very similar if you have separate encryption/integrity algorithms. The CryptoAPI for AEAD has slightly changed since then, so better have a look at the current implementation as well. Patch 9 in that series then exposes the implemented algorithm to IPsec. In strongSwan you'll have to add a proposal keyword, an algorithm identifier for the IKE exchange, and map that identifier to the kernel algorithm name you have chosen, see [2]. Regards Martin [1]https://www.spinics.net/lists/linux-crypto/msg15123.html [2]https://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=405c5dcd ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Different authentication methods
Hi Fred, authentication based on Windows Machine Certificates does not use IKEv2 EAP but directly employs IKEv2 public key authentication between VPN client and VPN gateway which very efficiently establishes an IPsec tunnel with a mere 4 IKEv2 messages. The Machine certificate must be installed in the "local machine" section of the Windows registry. User Certificates installed in the "current user" section of the registry as well as user smart cards cannot be used. IKEv2 EAP-TLS sets up a TLS session to an AAA server and is embedded into the encrypted IKEv2 message stream between VPN client and VPN gateway. Usually about 18 IKEv2 messages are needed to set up an IPsec tunnel thus the protocol is rather verbose. The advantage is that User Certificates installed in the "current user" section of the Windows registry can be used as well as user smart cards. The differentiation between Machine and User Certificates does apply to Windows clients only. On a strongSwan client you can use efficient IKEv2 public key authentication for any number of users. Best regards Andres On 11.04.2016 12:08, Fred wrote: hi all, These seem to be the industry norm for IKEv2: EAP-MSCHAPv2, Machine certificates (is this no EAP??), EAP-TLS, Just wondering how the bottom two use cases differ? What kind of scenario would better suit Machine Certificates over EAP-TLS with client certificates? Both seem to use certificates for auth of client, but am I right that one uses EAP and the other not? Is one weaker than the other or are they comparable? Thanks! Just hoping to choose the correct method and hoping to understand the real world differences between the two. Ta. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users -- == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[ITA-HSR]== smime.p7s Description: S/MIME Cryptographic Signature ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Different authentication methods
hi all, These seem to be the industry norm for IKEv2: EAP-MSCHAPv2, Machine certificates (is this no EAP??), EAP-TLS, Just wondering how the bottom two use cases differ? What kind of scenario would better suit Machine Certificates over EAP-TLS with client certificates? Both seem to use certificates for auth of client, but am I right that one uses EAP and the other not? Is one weaker than the other or are they comparable? Thanks! Just hoping to choose the correct method and hoping to understand the real world differences between the two. Ta. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Keeping VPN tunnel active
Is there a way in Strongswan to tell it to keep a tunnel active? I'm thinking here of devices, such as those running iOS, that do NOT have Always-On VPN easily available but where this behavour is desired. I'm not sure how Always On Vpn works anyway (is it proprietary?).Is there some standards compliant way of achieving this that will work across all devices (i.e. Windows clients, Android clients, iOS clients, Mac OS X)? I see there is an auto=route option to install a trap policy responder-side but if the initiator is a road-warrior with dynamic IP and the traffic is always going out from road-warrior to strongswan responder would this work anyway? Thanks. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
