OpenVPN with Hifn 7955 support
-
Good Morning
I have installed installed pfsense ver 1.0 with a Hifn 7955 chipset. When i login into the web administration interface pfsense display the crypto card fine. I have proceeded to setup a OpenVPN connection using ASE-128-CBC but I dont think that is is utilizing the Hifn 7955 chipset. I have started an ftp transfer over OpenVPN I get approx 280/K second with 100% cpu utilization. If I dont use OpenVPN I get 600/K second.
1. Is there a way i can check if openvpn is offloading the ssl?
2. Is there a parm I have to set to tell it to use Hifn 7955 chipset?Best Regards
-Ashley
-
I am not sure that this will work.
Check out http://lists.freebsd.org/pipermail/freebsd-security/2006-April/003651.html
Need to do some more research as I am not 100% sure of the answer to this one.
-
Thanks for the info is there a card that will do hardware crypto for openvpn. Whe I run the command on the 'openssl engine' pfsense box I get the following listed below… Nothing regarding the Hifn chipset support... But the pfsense document says it supports it.. Any feedback is welcome
openssl engine
(cryptodev) BSD cryptodev engine
(dynamic) Dynamic engine loading support
(cswift) CryptoSwift hardware engine support
(chil) nCipher hardware engine support
(atalla) Atalla hardware engine support
(nuron) Nuron hardware engine support
(ubsec) UBSEC hardware engine support
(padlock) VIA PadLock (no-RNG, no-ACE)
(aep) Aep hardware engine support
(sureware) SureWare hardware engine support
(4758cca) IBM 4758 CCA hardware engine support -
hifn will work for IPSEC.
-
Thanks for the response hoba. Is there any way or any card that will allow hardware accel for openvpn? Is this a issue with openvpn or pfsense?
Thanks Ashley
-
IMHO, hit up the OpenVPN lists. We have boxes here using the hifn accelerator, but not for OpenVPN. OpenVPN gets it's cryptographic strength by drawing entropy from /dev/random, and if you compile a pfSense kernel with the hifn chipset enabled, it will contribute entropy to /dev/random, thus you benefit.
In theory. You'll want to do your homework on this one. I have provide you the kernel compile parameters to build it in, but you'll have to do the compile yourself. A compile with hifn support built-in cannot be provided because (from personal experience) attempting to run a kernel with hifn support when no hifn card is present WILL result in kernel panics. Lots of them.
-
Thanks for the response hoba. Is there any way or any card that will allow hardware accel for openvpn? Is this a issue with openvpn or pfsense?
Thanks Ashley
I don't believe FreeBSD exposes the crypto hardware to userland and I'm not sure that it uses it to seed /dev/random It will however make use of it for IPSec. I suspect it's up to the userland code to make use of the crypto hardware itself (but I wouldn't have the slightest idea what that entails, sorry).
–Bill
-
billm, I hope you're wrong about this. Here's why:
I have a client that needed some serious entropy available to an application. We purchased a hifn card to supplement /dev/random. FreeBSD does not create /dev/hwrandom, and from all appearances, speed of the customer's application went waaay up, and the deployment passed some certification process that I was not involved in. So….hmm.
Interesting stuff. Perhaps I should dig into this further? BTW, another option if I recall correctly would be to insert a sound card, get the driver working, get the block device for the mic-in, then take and have that constantly dumping to /dev/random too. (don't hold me to that, never personally tried it!)
-
There is a big ongoing thread about all this right now on freebsd-current.
Do a search for hifn and userland.
-
billm, I hope you're wrong about this. Here's why:
I have a client that needed some serious entropy available to an application. We purchased a hifn card to supplement /dev/random. FreeBSD does not create /dev/hwrandom, and from all appearances, speed of the customer's application went waaay up, and the deployment passed some certification process that I was not involved in. So….hmm.
Interesting stuff. Perhaps I should dig into this further? BTW, another option if I recall correctly would be to insert a sound card, get the driver working, get the block device for the mic-in, then take and have that constantly dumping to /dev/random too. (don't hold me to that, never personally tried it!)
You're probably correct.
–Bill