Cryptographic Accelerators boards support in pfSense ?

mrzaz

I was reading a bit about the "Hardware Sizing Guidance", especially about VPN and started
to think about "there must be cryptographic hardware available for PC" as there are options to
other routers with this addons.

Made a small search on the internet and stumbled across the following page:
http://www.openbsd.org/crypto.html

From the pFSense page I looked at the "Hardware Compatibility List" and saw the following:


3.15 Cryptographic Accelerators

The hifn(4) driver supports various cards containing the Hifn 7751, 7951, 7811, 7955, and 7956 chipsets, such as:

 - Invertex AEON
 - Hifn 7751
 - PowerCrypt
 - XL-Crypt
 - NetSec 7751
 - Soekris Engineering vpn1201 and vpn1211
 - Soekris Engineering vpn1401 and vpn1411

The safe(4) driver supports cards containing any of the following chips:

 - SafeNet 1141
 - SafeNet 1741

The ubsec(4) driver supports cards containing any of the following chips:

 - Bluesteel 5501
 - Bluesteel 5601
 - Broadcom BCM5801
 - Broadcom BCM5802
 - Broadcom BCM5805
 - Broadcom BCM5820
 - Broadcom BCM5821
 - Broadcom BCM5822
 - Broadcom BCM5823

My question is:
Is any of this implemented in pfSense ?
(support/usage of Cryptographic Accelerators boards for IPSec/OpenVPN/PPTP etc.)

Best regards
Dan Lundqvist
Stockholm, Sweden
(Running pfSense incl. IPSec since 1.5 year)

hoba

The hifn-class of interfaces is supported and works. Not sure about the other drivers.

mrzaz

Hello Hoba,

This is nice. :-)
It could help out when handling a lot of VPN-tunnels offloading the CPU somewhat and
boosting up the overall VPN-performance and the CPU could handle more important stuff.

For me personally it's no big deal as right now I only have 1 IPSec tunnel and occasionly
some PPTP sessions but for other business who is running or planning on running pfSense
it could be important.

(I'm running the pfSense in an VMWare Server, with 2 physical NIC connected only to this
VM for performance and security reasons, so a crypto card is not likely supported by VM.)

Even if HW and addional Cryptocards is taken into account it is still much cheaper than
conventional routers in the same leage as pfSense. :-)

I think "you" should include this more clearly in the Features section as this would be
a good information for someone planning to use pfSense with VPN. (the support for CryptoCards)

Example of boards both for standard PC and WRAP:
Soekris Engineering vpn1401 and vpn1411
http://www.soekris.com/vpn1401.htm

Only around 50 euro. That's a bargain compared to what you have to pay for a cryptoboard for a Cisco.
Not to mention the price for the router with same/similar capabilities. ;-)

Best regards
Dan Lundqvist
Stockholm, Sweden

hoba

It will even show up at the system status screen when detected ;)

hifn.png_thumb

jmcentire

Is there anyway to get the Safenet 1141 to work? I currently have 3 machines with cards with the Safenet 1141 chip on them, currently pfsense doesn't recognize it. Any suggestions?
Thanks

sullrich

@jmcentire:

Is there anyway to get the Safenet 1141 to work? I currently have 3 machines with cards with the Safenet 1141 chip on them, currently pfsense doesn't recognize it. Any suggestions?
Thanks

If it is in the FreeBSD hardware compatibility guide then it will work. If it is not, then most likely not.

wallabybob

If it is in the FreeBSD hardware compatibility guide then it will work. If it is not, then most likely not.

This assumes the driver is built into the kernel. I don't have the kernel configuration file so I can't readily check if this is so.

Lets check if the device is detected by the OS as present in your system. From the shell prompt do

pciconf -l -v

dmesg

and post the results.

There are many possibilities. This output will help to eliminate a few.

jmcentire

Here it is (BTW this is a SafeNet 1141 mini-pci card, and according to the HCL it should be supported):
$ pciconf -l -v
hostb0@pci0:0:0: class=0x060000 card=0x11308086 chip=0x11308086 rev=0x04 hdr=0x00
class = bridge
subclass = HOST-PCI
pcib1@pci0:30:0: class=0x060400 card=0x00000000 chip=0x244e8086 rev=0x05 hdr=0x01
class = bridge
subclass = PCI-PCI
isab0@pci0:31:0: class=0x060100 card=0x00000000 chip=0x24408086 rev=0x05 hdr=0x00
class = bridge
subclass = PCI-ISA
atapci0@pci0:31:1: class=0x010180 card=0x24408086 chip=0x244b8086 rev=0x05 hdr=0x00
class = mass storage
subclass = ATA
none0@pci2:6:0: class=0xff0000 card=0x00010001 chip=0x114116ae rev=0x01 hdr=0x00
re0@pci2:9:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00
class = network
subclass = ethernet
re1@pci2:10:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00
class = network
subclass = ethernet
re2@pci2:11:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00
class = network
subclass = ethernet
re3@pci2:12:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00
class = network
subclass = ethernet
re4@pci2:13:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00
class = network
subclass = ethernet
re5@pci2:14:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00
class = network
subclass = ethernet

$ dmesg
Copyright 1992-2007 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 is a registered trademark of The FreeBSD Foundation.
FreeBSD 6.2-RELEASE-p11 #0: Sun Feb 24 16:38:29 EST 2008
sullrich@builder6.pfsense.com:/usr/obj.pfSense/usr/src/sys/pfSense_wrap.6
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) III CPU family 1400MHz (1403.19-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1
Features=0x383f9ff <fpu,vme,de,pse,tsc,msr,pae,mce,cx8,sep,mtrr,pge,mca,cmov,pat,pse36,mmx,fxsr,sse>real memory = 268435456 (256 MB)
avail memory = 253267968 (241 MB)
wlan: mac acl policy registered
ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
cpu0 on motherboard
pcib0: <intel 82815="" (i815="" gmch)="" host="" to="" hub="" bridge="">pcibus 0 on motherboard
pir0: <pci 11="" interrupt="" routing="" table:="" entries="">on motherboard
$PIR: Using invalid BIOS IRQ 9 from 2.13.INTA for link 0x63
pci0: <pci bus="">on pcib0
pcib1: <pcibios pci-pci="" bridge="">at device 30.0 on pci0
pci2: <pci bus="">on pcib1
pci2: <unknown>at device 6.0 (no driver attached)
re0: <realtek 10="" 8139c+="" 100basetx="">port 0xd500-0xd5ff mem 0xefefa000-0xefefa1ff irq 10 at device 9.0 on pci2
miibus0: <mii bus="">on re0
rlphy0: <realtek internal="" media="" interface="">on miibus0
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re0: Ethernet address: 00:90:7f:32:cb:fe
re0: [FAST]
re1: <realtek 10="" 8139c+="" 100basetx="">port 0xd600-0xd6ff mem 0xefefb000-0xefefb1ff irq 5 at device 10.0 on pci2
miibus1: <mii bus="">on re1
rlphy1: <realtek internal="" media="" interface="">on miibus1
rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re1: Ethernet address: 00:90:7f:32:cb:ff
re1: [FAST]
re2: <realtek 10="" 8139c+="" 100basetx="">port 0xd900-0xd9ff mem 0xefefc000-0xefefc1ff irq 11 at device 11.0 on pci2
miibus2: <mii bus="">on re2
rlphy2: <realtek internal="" media="" interface="">on miibus2
rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re2: Ethernet address: 00:90:7f:32:cc:00
re2: [FAST]
re3: <realtek 10="" 8139c+="" 100basetx="">port 0xda00-0xdaff mem 0xefefd000-0xefefd1ff irq 12 at device 12.0 on pci2
miibus3: <mii bus="">on re3
rlphy3: <realtek internal="" media="" interface="">on miibus3
rlphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re3: Ethernet address: 00:90:7f:32:cc:01
re3: [FAST]
re4: <realtek 10="" 8139c+="" 100basetx="">port 0xdd00-0xddff mem 0xefefe000-0xefefe1ff irq 9 at device 13.0 on pci2
miibus4: <mii bus="">on re4
rlphy4: <realtek internal="" media="" interface="">on miibus4
rlphy4: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re4: Ethernet address: 00:90:7f:32:cc:02
re4: [FAST]
re5: <realtek 10="" 8139c+="" 100basetx="">port 0xde00-0xdeff mem 0xefeff000-0xefeff1ff irq 6 at device 14.0 on pci2
miibus5: <mii bus="">on re5
rlphy5: <realtek internal="" media="" interface="">on miibus5
rlphy5: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re5: Ethernet address: 00:90:7f:32:cc:03
re5: [FAST]
isab0: <pci-isa bridge="">at device 31.0 on pci0
isa0: <isa bus="">on isab0
atapci0: <intel ich2="" udma100="" controller="">port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.1 on pci0
ata0: <ata 0="" channel="">on atapci0
ata1: <ata 1="" channel="">on atapci0
orm0: <isa option="" rom="">at iomem 0xe0000-0xe0fff on isa0
ppc0: <parallel port="">at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/16 bytes threshold
ppbus0: <parallel port="" bus="">on ppc0
ppi0: <parallel i="" o="">on ppbus0
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
unknown: <pnp0c01>can't assign resources (memory)
speaker0: <pc speaker="">at port 0x61 on isa0
unknown: <pnp0501>can't assign resources (port)
unknown: <pnp0401>can't assign resources (port)
RTC BIOS diagnostic error 20 <config_unit>Timecounter "TSC" frequency 1403186372 Hz quality 800
Timecounters tick every 10.000 msec
Fast IPsec: Initialized Security Association Processing.
ad2: DMA limited to UDMA33, controller found non-ATA66 cable
ad2: 76319MB <wdc wd800beve-00uyt0="" 01.04a01="">at ata1-master UDMA33</wdc></config_unit></pnp0401></pnp0501></pc></pnp0c01></parallel></parallel></parallel></isa></ata></ata></intel></isa></pci-isa></realtek></mii></realtek></realtek></mii></realtek></realtek></mii></realtek></realtek></mii></realtek></realtek></mii></realtek></realtek></mii></realtek></unknown></pci></pcibios></pci></pci></intel></fpu,vme,de,pse,tsc,msr,pae,mce,cx8,sep,mtrr,pge,mca,cmov,pat,pse36,mmx,fxsr,sse>

sullrich

Doesn't look like we had device safe in our kernel configuration file. I just added it and it will show up in future versions.

jmcentire

Is there any way I can update that on one of my systems, at least for testing?

Thanks

sullrich

Rebuild the kernel, but you are on your own.

jmcentire

I guess I will wait for the next version ;)
Thanks

dotdash

You could try copying safe.ko from a stock FreeBSD 6.2 install into your /boot/kernel directory, then adding safe_load="YES" to loader.conf

jmcentire

dotdash: Tried what you said, here is what I get on boot up:

safe0 mem 0xefbfe000-0xefbfffff irq 3 at device 6.0 on pci2
safe0: cannot allocate DMA tag
device_attach: safe0 attach returned 6
re0: <realtek 10="" 8139c+="" 100basetx="">port 0xd500-0xd5ff mem 0xefefa000-0xefefa1ff
irq 10 at device 9.0 on pci2
re0: could not allocate dma tag

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x60
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc057c995
stack pointer = 0x28:0xc0c20b5c
frame pointer = 0x28:0xc0c20b70
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
Uptime: 1s
Automatic reboot in 15 seconds - press a key on the console to abort</realtek>

sullrich

@dotdash:

You could try copying safe.ko from a stock FreeBSD 6.2 install into your /boot/kernel directory, then adding safe_load="YES" to loader.conf

Nice can of worms you just opened :)

jmcentire

Worth a try, don't really feel like doing real work on a friday afternoon anyway ;D

BTW popped out the card and it boots just fine, so don't worry about causing any problems dotdash.

sullrich

:) :)

dotdash

@jmcentire:

dotdash: Tried what you said, here is what I get on boot up:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x60
fault code = supervisor read, page not present

Whoops. Well, I didn't say it was a good idea…
If you're still feeling brave, it would be interesting to see what happened if you removed it from loader.conf and tried loading it after the system was booted with 'kldload safe'
Is the card in the original slot? It almost looks like an IRQ conflict?

jmcentire

@dotdash:

If you're still feeling brave, it would be interesting to see what happened if you removed it from loader.conf and tried loading it after the system was booted with 'kldload safe'
Is the card in the original slot? It almost looks like an IRQ conflict?

Yup, in the original slot.

kldload safe

safe0 mem 0xefbfe000-0xefbfffff irq 3 at device 6.0 on pci2
safe0: cannot allocate DMA tag
device_attach: safe0 attach returned 6

dotdash

This appears to be a known bug in 6.2
http://www.freebsd.org/cgi/query-pr.cgi?pr=110662&cat=kern