[Swan] Libreswan Performance

Craig Marker cmarker at inspeednetworks.com
Thu Mar 30 19:34:03 UTC 2017


Hey Paul,

I took the advice you mentioned, and have gotten the pcrypt module working. Surprisingly, Strongswan’s wiki provided me enough information
to get it working on my system. Thanks for the quick feedback! Of note, I was not able to get the crconf way working..

I’m on kernel version 3.10.0-514.10.2.el7.x86_64 and am running Centos 7.3.

Interestingly, though, depending on sequence of events, I either get dramatically better performance, or my system reboots! The dramatically
better performance is an improvement from ~230Mbps to upwards of 500/600Mbps. That is awesome! However, the sequence that causes reboot
is the sequence I would prefer to run on my system.

The sequence that works successfully is as follows: **Note: all modprobe commands are ONLY run on tunnel endpoint A.

1. Reboot system
2. Connect IPsec tunnels, configuration shown below
3. modprobe pcrypt
4. modprobe tcrypt alg="pcrypt(rfc4106(gcm(aes)))" type=3
5. Reconnect IPsec tunnels, same configuration.

The sequence that causes reboot is as follows:

1. Reboot system
2. modprobe pcrypt
3. modprobe tcrypt alg="pcrypt(rfc4106(gcm(aes)))" type=3
4. Connect IPsec tunnels, configuration shown below.
5. Ping across tunnel


Tunnel endpoint A:
config setup
dumpdir=/var/run/pluto/
virtual-private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v4:100.64.0.0/10,%v6:fd00::/8,%v6:fe80::/10
protostack=netkey

# begin conn local
conn local
left=10.200.0.210
leftid="@client"
leftsubnet=0.0.0.0/0
leftcert=client
rightid="@is1"
rightsubnet=0.0.0.0/0
right=10.200.0.92
authby=rsasig
vti-routing=no
encapsulation=yes
mark=1/0xffffffff
vti-interface=vti01
phase2alg=aes_gcm-null
auto=ignore
type=tunnel
compress=no
pfs=yes
ikepad=yes
authby=rsasig
phase2=esp
ikev2=permit
esn=no
# end conn local

Tunnel endpoint B:
config setup
dumpdir=/var/run/pluto/
virtual-private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v4:100.64.0.0/10,%v6:fd00::/8,%v6:fe80::/10
protostack=netkey

# begin conn local
conn local
left=10.200.0.210
leftid="@client"
leftsubnet=0.0.0.0/0
rightid="@is1"
rightsubnet=0.0.0.0/0
right=10.200.0.92
rightcert=server
authby=rsasig
vti-routing=no
encapsulation=yes
mark=1/0xffffffff
vti-interface=vti01
phase2alg=aes_gcm-null
auto=ignore
type=tunnel
compress=no
pfs=yes
ikepad=yes
authby=rsasig
phase2=esp
ikev2=permit
esn=no
# end conn local

I’m going to keep looking to try and understand why this is happening. There is nothing in the logs that raises any red flags. Let me know
if you can think of anything I should look out for. I’ve tried playing around with the sequence a bit, but none of my attempts have been
successful

--
cm

On Mar 29, 2017, at 9:59 AM, Paul Wouters <paul at nohats.ca<mailto:paul at nohats.ca>> wrote:

Oh I misunderstood.

You can try increasing the replay-window or disabling replay detection
using replay-window=64 or replay-window=0

Ensure you are using AES_GCM as ESP algorithm for best performance.

You can try to load the pcrypt kernel module to use multiple CPU's, but
the documentation of the pcrypt module is non-existent and existing
examples you find on a google search are wrong. I would be interested
if you can get this to work.

There are also ethernet hardware and offload tweaking that is possible.

Some links that might help:

https://libreswan.org/wiki/Benchmarking_and_Performance_testing
https://wiki.strongswan.org/projects/strongswan/wiki/Pcrypt

Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20170330/7a21ae4d/attachment.html>


More information about the Swan mailing list