Re: VIA/ACE PadLock integration with crypto(9).

From: Mike Tancsa <mike_at_sentex.net>
Date: Sat, 13 Aug 2005 01:45:44 -0400
At 09:45 AM 12/08/2005, Pawel Jakub Dawidek wrote:

>The thing which interest me the most is how it works with fast_ipsec(4).

I have been trying to get it to work but I am not sure if its 
registering or not. I can certainly see a big different with GELI, 
but with the box acting as a router, iperf shows essentially identical results.


FreeBSD itx-vpn.sentex.ca 6.0-BETA2 FreeBSD 6.0-BETA2 #1: Fri Aug 12 
23:07:23 EDT 2005     mdtancsa_at_itx-vpn.sentex.ca:/usr/obj/usr/src/sys/itx  i386

[itx-vpn]# kldstat
Id Refs Address    Size     Name
  1    5 0xc0400000 458ff0   kernel
  2   16 0xc0859000 55ffc    acpi.ko
  3    1 0xc1fb8000 3000     padlock.ko
[itx-vpn]#


RELENG_5 box
setkey -c <<EOF
        add 172.16.1.3 172.16.1.4 esp 1044 -m  any -E rijndael-cbc 
"12345678901234561234567890123456" ;
        add 172.16.1.4 172.16.1.3 esp 1044 -m any -E rijndael-cbc 
"12345678901234561234567890123456"  ;
        spdadd 10.99.98.0/23  192.168.42.0/23 any -P out ipsec 
esp/tunnel/172.16.1.3-172.16.1.4/require ;
        spdadd 192.168.42.0/23 10.99.98.0/23  any -P in ipsec 
esp/tunnel/172.16.1.4-172.16.1.3/require ;
EOF

RELENG_6 box

setkey -c <<EOF
        add 172.16.1.4 172.16.1.3 esp 1044 -m  any -E rijndael-cbc 
"12345678901234561234567890123456" ;
        add 172.16.1.3 172.16.1.4 esp 1044 -m any -E rijndael-cbc 
"12345678901234561234567890123456" ;
        spdadd 192.168.42.0/23 10.99.98.0/23 any -P out ipsec 
esp/tunnel/172.16.1.4-172.16.1.3/require ;
        spdadd 10.99.98.0/23 192.168.42.0/23 any -P in ipsec 
esp/tunnel/172.16.1.3-172.16.1.4/require ;
EOF

Yet the iperf results are the same with and without the module 
loaded.  When I use the hifn cards, I have it compiled into the 
kernel and I do see a difference, especially on the soekris 
boxes.  However, on

Copyright (c) 1992-2005 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
         The Regents of the University of California. All rights reserved.
FreeBSD 6.0-BETA2 #1: Fri Aug 12 23:07:23 EDT 2005
     mdtancsa_at_itx-vpn.sentex.ca:/usr/obj/usr/src/sys/itx
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: VIA C3 Nehemiah+RNG+ACE (796.77-MHz 686-class CPU)
   Origin = "CentaurHauls"  Id = 0x698  Stepping = 8
   Features=0x381b03f<FPU,VME,DE,PSE,TSC,MSR,MTRR,PGE,CMOV,PAT,MMX,FXSR,SSE>
real memory  = 467599360 (445 MB)
avail memory = 448204800 (427 MB)

its essentially the same


I have setup RELENG_5 -FastE--- RELENG_6----FastE--clientbox

clientbox hits the inside VPN interface of the RELENG_5 box via iperf 
going across RELENG_6 which is the via/ACE enabled box

iperf -c 10.99.98.1

Point to point, I essentially get close to FastE
[  4] local 172.16.1.3 port 5001 connected with 172.16.1.4 port 57661
[  4]  0.0-10.0 sec    112 MBytes  94.1 Mbits/sec
[  4] local 172.16.1.3 port 5001 connected with 172.16.1.4 port 57913
[  4]  0.0-10.0 sec    111 MBytes  93.2 Mbits/sec

going from clientbox across the tunnel with and without the padlock, 
its essentially identical which is odd

without
[  4]  0.0-10.0 sec  31.2 MBytes  26.1 Mbits/sec
[  4] local 10.99.98.1 port 5001 connected with 192.168.43.34 port 62827
[  4]  0.0-10.0 sec  30.9 MBytes  25.9 Mbits/sec
[  4] local 10.99.98.1 port 5001 connected with 192.168.43.34 port 56683
[  4]  0.0-10.0 sec  30.8 MBytes  25.8 Mbits/sec
[  4] local 10.99.98.1 port 5001 connected with 192.168.43.34 port 58964

with padlock.ko loaded


[  4]  0.0-10.0 sec  30.7 MBytes  25.8 Mbits/sec
[  4] local 10.99.98.1 port 5001 connected with 192.168.43.34 port 62982
[  4]  0.0-10.0 sec  31.2 MBytes  26.1 Mbits/sec
[  4] local 10.99.98.1 port 5001 connected with 192.168.43.34 port 65003
[  4]  0.0-10.0 sec  31.3 MBytes  26.3 Mbits/sec


Is there something else that needs to be done to tell crypto(4) or 
FAST_IPSEC to use the "hardware" in this case ?

Also,   I came across a small ipsec bug while testing

http://www.freebsd.org/cgi/query-pr.cgi?pr=84860



         ---Mike 
Received on Sat Aug 13 2005 - 03:48:31 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:41 UTC