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 <[email protected]<mailto:[email protected]>> 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
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
