[Swan] Poor OpenSwan IPsec Performance
dave at ariens.ca
dave at ariens.ca
Thu Aug 15 17:48:32 EEST 2013
> Try switching between 3DES and AES. That should show a difference only
> if the CPU is the bottleneck.
Corect, I am using netkey.
Configuring ike=3des-sha1;modp1536 exhibits identical poor performance.
Utilization is also very low during the tranfser regardless of IKE
configuration, load average of around 0.02, 0.02, 0.05.
> netkey uses 1 CPU per SA only. Can you setup two SA's between the
> endpoint and run two of these at the same time to see what happens?
Copying the 1.6GB test file over a 2nd tunnel (both http wget) from two
different remote hosts (both tunnels 3des-sha1) generates identical
results. Load average stays about the same, and both transfer speeds
are the same.
I'm noticing some duplicate ACK's in a tcpdump which are not present if
I copy the file without going through the tunnel (which is 10x faster).
I am not a TCP guru, and have limited troubleshooting abilities in this
arena...
2013-08-15 09:47, Paul Wouters wrote:
> On Wed, 14 Aug 2013, dave at ariens.ca wrote:
>
>> [Originally posted to users at lists.openswan.org]
>>
>> Hey there, to add a few extra details:
>>
>> Version: openswan 2.6.39-2
>> CPU: Dual Core Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz
>>
>> I'm fairly sure we're not looking at a CPU bottleneck and additional
>
> Try switching between 3DES and AES. That should show a difference only
> if the CPU is the bottleneck.
>
>> pondering has me looking at MTU size and packet fragmentation... I've
>> attempted to force the Openswan server to send the fragmentation
>> requirement with fragicmp=yes, and ensured that those packets were
>> allowed through the
>
> Are you using KLIPS? fragicmp= is a klips-only option. Note that
> libreswan has seen a fix compared to openswan with KLIPS and
> fragmentation, that did impact performance. KLIPS was always
> fragmenting
> packets due to (wrong?) size calculations. (Looking below, it looks
> like
> you are using NETKEY, so this does not apply)
>
> netkey uses 1 CPU per SA only. Can you setup two SA's between the
> endpoint and run two of these at the same time to see what happens?
>
> Paul
>
>> firewall (-A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT)
>> all to no benefit. I've set the MTU size on the interface
>> higher/lower, also to no avail.
>>
>> I'm excited to see Libreswan get off the group and look forward to
>> migrating to the next release.
>>
>> Original Mail:
>>
>> Hi,
>>
>> I have 2 VPS servers running OpenSwan that have tunnels between
>> themselves and a tunnel to a Juniper SRX firewall on my home network.
>>
>> The VPS servers both have 100Mbit/s Internet connections (real-world
>> throughput, both up and down, is excellent). My home network has a
>> 30Mbit/s cable broadband connection (also excellent).
>>
>> I have a 1.6GB test file that I'm copying around (both from VPS1 <->
>> VPS2, and VPS1/2 -> home) and I cannot get higher than ~ 1.5Mbit/s
>> transer speeds going over the tunnel whereas non-encrypted transfers
>> are what you would expect: ~95% of connection capabilities.
>>
>> I've read some search results that indicated that the encryption
>> algorithms in play can impact throughput, but I don't suspect they
>> would be reducing my transfer speeds by > 90%. CPU load on both VPS
>> servers was extremely low during all tests.
>>
>> Here's a snippet of the tunnel properties, any and all help would be
>> very appreciated!
>>
>> # ipsec auto --status
>> 000 using kernel interface: netkey
>> 000 interface lo/lo ::1
>> 000 interface lo/lo 127.0.0.1
>> 000 interface lo/lo 127.0.0.1
>> 000 interface eth0/eth0 1.1.1.1
>> 000 interface eth0/eth0 1.1.1.1
>> 000 interface eth0/eth0 192.168.100.10
>> 000 interface eth0/eth0 192.168.100.10
>> 000 %myid = (none)
>> 000 debug none
>> 000
>> 000 virtual_private (%priv):
>> 000 - allowed 6 subnets: 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12,
>> 25.0.0.0/8, fd00::/8, fe80::/10
>> 000 - disallowed 1 subnet: 192.168.100.0/24
>> 000
>> 000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64,
>> keysizemax=64
>> 000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8,
>> keysizemin=192, keysizemax=192
>> 000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8,
>> keysizemin=40, keysizemax=128
>> 000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8,
>> keysizemin=40, keysizemax=448
>> 000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0,
>> keysizemin=0, keysizemax=0
>> 000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8,
>> keysizemin=128, keysizemax=256
>> 000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8,
>> keysizemin=160, keysizemax=288
>> 000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8,
>> keysizemin=128, keysizemax=256
>> 000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8,
>> keysizemin=128, keysizemax=256
>> 000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8,
>> keysizemin=128, keysizemax=256
>> 000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8,
>> keysizemin=160, keysizemax=288
>> 000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=12,
>> keysizemin=160, keysizemax=288
>> 000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=16,
>> keysizemin=160, keysizemax=288
>> 000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8,
>> keysizemin=128, keysizemax=256
>> 000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8,
>> keysizemin=128, keysizemax=256
>> 000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8,
>> keysizemin=128, keysizemax=256
>> 000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5,
>> keysizemin=128, keysizemax=128
>> 000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1,
>> keysizemin=160, keysizemax=160
>> 000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256,
>> keysizemin=256, keysizemax=256
>> 000 algorithm ESP auth attr: id=6, name=AUTH_ALGORITHM_HMAC_SHA2_384,
>> keysizemin=384, keysizemax=384
>> 000 algorithm ESP auth attr: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512,
>> keysizemin=512, keysizemax=512
>> 000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD,
>> keysizemin=160, keysizemax=160
>> 000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC,
>> keysizemin=128, keysizemax=128
>> 000 algorithm ESP auth attr: id=251, name=AUTH_ALGORITHM_NULL_KAME,
>> keysizemin=0, keysizemax=0
>> 000
>> 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16,
>> keydeflen=131
>> 000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8,
>> keydeflen=192
>> 000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16,
>> keydeflen=128
>> 000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
>> 000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
>> 000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, hashsize=32
>> 000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashsize=64
>> 000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024,
>> bits=1024
>> 000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536,
>> bits=1536
>> 000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048,
>> bits=2048
>> 000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072,
>> bits=3072
>> 000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096,
>> bits=4096
>> 000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144,
>> bits=6144
>> 000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192,
>> bits=8192
>> 000 algorithm IKE dh group: id=22, name=OAKLEY_GROUP_DH22, bits=1024
>> 000 algorithm IKE dh group: id=23, name=OAKLEY_GROUP_DH23, bits=2048
>> 000 algorithm IKE dh group: id=24, name=OAKLEY_GROUP_DH24, bits=2048
>> 000
>> 000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0}
>> trans={0,0,0} attrs={0,0,0}
>> 000
>> 000 "home.domain.ca":
>> 0.0.0.0/0===1.1.1.1<1.1.1.1>...1.1.1.3<1.1.1.3>===10.0.0.0/8; erouted;
>> eroute owner: #9
>> 000 "home.domain.ca": myip=192.168.100.10; hisip=unset;
>> 000 "home.domain.ca": ike_life: 3600s; ipsec_life: 28800s;
>> rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
>> 000 "home.domain.ca": policy:
>> PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 0,8;
>> interface: eth0;
>> 000 "home.domain.ca": newest ISAKMP SA: #5; newest IPsec SA: #9;
>> 000 "home.domain.ca": IKE algorithm newest:
>> 3DES_CBC_192-SHA1-MODP1024
>> 000 "vps2":
>>
>>
>> 8.100.10/32===1.1.1.1<1.1.1.1>...1.1.1.2<1.1.1.2>===192.168.200.10/32;
>> erouted; eroute owner: #11
>> 000 "vps2": myip=192.168.100.10; hisip=unset;
>> 000 "vps2": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
>> rekey_fuzz: 100%; keyingtries: 0
>> 000 "vps2": policy:
>> PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio:
>> 32,32; interface: eth0;
>> 000 "vps2": newest ISAKMP SA: #10; newest IPsec SA: #11;
>> 000 "vps2": IKE algorithm newest: AES_CBC_128-SHA1-MODP2048
>> 000
>> 000 #9: "home.domain.ca":500 STATE_QUICK_R2 (IPsec SA established);
>> EVENT_SA_REPLACE in 27417s; newest IPSEC; eroute owner; isakmp#1;
>> idle; import:admin initiate
>> 000 #9: "home.domain.ca" esp.6bdbad6 at 1.1.1.3 esp.f7dad11f at 1.1.1.1
>> tun.0 at 1.1.1.3 tun.0 at 1.1.1.1 ref=0 refhim=4294901761
>> 000 #1: "home.domain.ca":500 STATE_MAIN_I4 (ISAKMP SA established);
>> EVENT_SA_REPLACE in 1497s; lastdpd=880s(seq in:0 out:0); idle;
>> import:admin initiate
>> 000 #5: "home.domain.ca":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA
>> established); EVENT_SA_REPLACE in 2160s; newest ISAKMP;
>> lastdpd=-1s(seq in:0 out:0); idle; import:not set
>> 000 #11: "vps2":500 STATE_QUICK_R2 (IPsec SA established);
>> EVENT_SA_REPLACE in 27577s; newest IPSEC; eroute owner; isakmp#10;
>> idle; import:not set
>> 000 #11: "vps2" esp.7e679ad6 at 1.1.1.2 esp.9c1dfcbe at 1.1.1.1
>> tun.0 at 1.1.1.2 tun.0 at 1.1.1.1 ref=0 refhim=4294901761
>> 000 #10: "vps2":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
>> EVENT_SA_REPLACE in 2377s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0);
>> idle; import:not set
>> _______________________________________________
>> Swan mailing list
>> Swan at lists.libreswan.org
>> https://lists.libreswan.org/mailman/listinfo/swan
>>
More information about the Swan
mailing list