Date: Fri, 10 Aug 2018 18:47:07 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: "David P. Discher" <dpd@dpdtech.com> Cc: "Andrey V. Elsukov" <bu7cher@yandex.ru>, freebsd-net@freebsd.org Subject: Re: Is if_ipsec/ipsec - AESNI accelerated ? Message-ID: <20180811014707.GB97145@funkthat.com> In-Reply-To: <BE275E67-A768-47E9-97D4-0A5E4FDC44EF@dpdtech.com> References: <D47976AF-A0AF-4A58-B80E-31E9DED96D26@dpdtech.com> <dc8bea35-1770-48d0-3662-c58e72bd3d2d@yandex.ru> <62E0C365-AD64-4383-8BA4-298AA0E292F4@dpdtech.com> <e9da62df-90e4-e45b-b073-c4c39555b38d@yandex.ru> <BE275E67-A768-47E9-97D4-0A5E4FDC44EF@dpdtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David P. Discher wrote this message on Thu, Aug 09, 2018 at 13:11 -0700: > The documentation for using IPSec (especially if_ipsec) is really thin for freebsd, so I pieced some of this together from various posts and mailing lists threads. > > Is there no need for racoon ? How in this example is the IKE/ISAKMP setup done ? Is setkey doing this ? Yeah, it is... A few of us have sample config files floating around.. When I was doing testing I used: https://github.com/jmgurney/ipseccfgs > > On Aug 9, 2018, at 1:32 AM, Andrey V. Elsukov <bu7cher@yandex.ru> wrote: > > > > # kldload aesni > > # setkey -DF > > # setkey -c > > add 10.0.0.25 10.0.0.15 esp 10000 -m tunnel -u 16385 -E rijndael-cbc > > "0123456789123456"; > > add 10.0.0.15 10.0.0.25 esp 20000 -m tunnel -u 16385 -E rijndael-cbc > > "0123456789123456"; > > > > # sysctl net.inet.ipsec.async_crypto=0 > > net.inet.ipsec.async_crypto: 1 -> 0 > > This is 11.2-stable, shortly after release ??? I don???t have this sysctl. > > [ pts/0 sjc2 util201:~ ] > [ dpd ] > sysctl net.inet.ipsec > net.inet.ipsec.def_policy: 1 > net.inet.ipsec.esp_trans_deflev: 1 > net.inet.ipsec.esp_net_deflev: 1 > net.inet.ipsec.ah_trans_deflev: 1 > net.inet.ipsec.ah_net_deflev: 1 > net.inet.ipsec.ah_cleartos: 1 > net.inet.ipsec.dfbit: 0 > net.inet.ipsec.ecn: 0 > net.inet.ipsec.debug: 0 > net.inet.ipsec.filtertunnel: 0 > net.inet.ipsec.natt_cksum_policy: 0 > net.inet.ipsec.check_policy_history: 0 > net.inet.ipsec.crypto_support: 50331648 > > > > > On Aug 9, 2018, at 6:40 AM, John-Mark Gurney <jmg@funkthat.com> wrote: > > > > > > You don't show what ciphers you are using. It could be that you're > > using CBC mode, which is known to be slow, or that you're using a > > slow AH that is limiting performance, and not the cipher... > > > > Need to see your setkey.conf, or at least the output of setkey -D.. > > racoon.conf is : > > sainfo anonymous > { > pfs_group 2; > lifetime time 86400 seconds; > encryption_algorithm aes; > authentication_algorithm hmac_sha256; > compression_algorithm deflate; > } > > remote 10.245.0.202 [500] { > passive off; > my_identifier address 172.30.1.13; > exchange_mode main; > lifetime time 24 hour; > proposal { > encryption_algorithm aes; > hash_algorithm sha1; > authentication_method pre_shared_key; > dh_group 2; > }} > > > For some reason, I don???t think I can use AES-GCM on the juniper side, because of a combination of other required settings. I remember trying, but don???t remember why I can???t. > > > setkey.conf is : > > flush; > spdflush; > > spdadd -4n 172.30.1.12/30 172.30.1.12/30 any -P out ipsec esp/tunnel/10.245.0.201-10.245.0.202/unique:12; > spdadd -4n 172.30.1.12/30 172.30.1.12/30 any -P in ipsec esp/tunnel/10.245.0.202-10.245.0.201/unique:12; > spdadd -4n 172.30.1.4/30 172.30.1.4/30 any -P out ipsec esp/tunnel/10.245.0.201-10.245.0.203/unique:4; > spdadd -4n 172.30.1.4/30 172.30.1.4/30 any -P in ipsec esp/tunnel/10.245.0.203-10.245.0.201/unique:4; > > And that results in : > > [ pts/0 sjc2 util201:~ ] > [ dpd ] > sudo setkey -D > Password: > 10.245.0.201 10.245.0.202 > esp mode=tunnel spi=60080461(0x0394c14d) reqid=12(0x0000000c) > E: rijndael-cbc xxxx > A: hmac-sha2-256 xxxx Yeah, this is AES-CBC, and will always be slow on encryption, decryption will be fast though... To get max possible speed (per core), you can run: openssl speed -evp aes-128-cbc I believe that crypto will be single threaded on output, so you could try to enable net.inet.ipsec.async_crypto and see if that helps.. This will let your sending process be on one core while handing the encryption off to another thread... If you were running HEAD, you'd also get further improvements by there being multiple threads doing processing, but it looks like that change hasn't been MFC'd yet... Switching to SHA2-512 will also improve performance on 64bit systems... Also, check to make sure that the various processes are consuming 100% usage, and likely you'll see that.. Also, try running multiple streams to see if you get better performance, you should get signifcantly better performance as that'll split the work among multiple threads... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180811014707.GB97145>