PfSense on a Riverbed Steelhead
-
WARNING: These instructions apply to older 32bit CX-250/550 Steelheads. Steelheads in the CX-570/770 and possibly the x55 generation, have BIOS settings for controlling bypass NICS. Please do not use the method below if your Steelhead offers BIOS controls.
Here’s what I hope is a full soup-to-nuts process for getting pfSense 2.3.5 up and running on these boxes with all 4 nics active…
Prep work and nic mapping info:
-Remove the internal USBDOM boot device, label it and keep it safe incase you ever want to run as a Steelhead again
-Remove the internal HDD (remove the whole drive cage, just 3 screws and lift the cage straight up and out)
-Optional: Label and put the original HDD aside and keep it safe incase you ever want to run as a Steelhead again-Nic mapping in pfSense compared to front panel labeling:
em0 = LAN0_0
em1 = WAN0_0
em2 = Primary
em3 = AuxBIOS setup:
-Connect to serial port using 9600 8,none,1 then power up-Hit Delete key during BIOS initialization, use “minnow” when prompted for a password and change these settings…
-Exit Menu -> Load Optimal Defaults (do this first)
-Advanced Setting Menu -> Configure Remote access -> Serial Port Mode “115200 8,n,1”
-Optional: Boot Menu -> Quick Boot “Disabled” (this will give you more time to hit the Delete key and plug USB devices in in the future)
-Boot Menu -> Boot Settings Config -> USBDOM Boot Only “Disabled”
-Boot Menu -> Boot Device Priority (should not need to be changed, but take note and adjust if needed)
-Exit Menu -> Save Changes and Exit -> Hit Enter twice to save changes
Note regarding the roundabout installation instructions below:
Unfortunately attempting to install pfSense 2.3.5 directly to an internal SATA drive fails, getting stuck with messagings like…
(ada0:ahcich0:0:0:0): CAM status: Command timeout
(ada0:ahcich0:0:0:0): Retrying command
FWIW newer versions of FreeBSD have no such issue, v12.1 for example installs directly to an internal SATA drive just fine.pfSense 2.3.5 Installation:
-Switch your serial port terminal settings to 115200 8, none, 1 (you should never have to crawl at 9600 again)-Insert a USB key with the installer in the top USB port on the front panel (shows as da0 in pfSense)
-Connect a SATA drive via USB-to-SATA adapter to the bottom USB port on the front panel (shows as da1 in pfSense)
—Note my SATA drive would not power up from a cold start, I had to plug it in after power-up, during the memory count-Power up and the box should automatically boot from the USB key
—If not, leave the USB key and SATA drive connected, reboot into the BIOS and set to boot off the USB key and reboot-Hit “I” to launch the Installer or let it boot automatically
-Install pfSense per standard instructions (Quick/Easy Install worked for me)
-Choose “Embedded kernel (no VGA console, keyboard”) when prompted
-Reboot when prompted and power down
-Remove the USB key
-Move the SATA drive to the top slot of the internal drive cage and this will now show up as ada0
—Note if you install a 2nd drive in the bottom bay it will show up as ada1-Power-up and pfSense should boot from the internal SATA drive
-Configure the LAN and WAN ports to em2 and em3 (my recommendation is em2=LAN em3=WAN)
—Why not use em0 and em1 for LAN and WAN? Because em0 and em1 CAN be set to bypass/bridge mode which causes them to act as a hard wired crossover coupler. This is the normal mode of these nics when running Steelhead software. In that state, EVERYTHING will pass between them like a wire, regardless of power being on or off. Not good for a firewall unless you have a special need for this capability.
—Special note regarding POE and em0/em1: These boxes have a design defect related to POE so you MUST use the supplied 2-port dongle if you intend to connect em0 and em1 to POE ports. Doing so without the dongle risks damaging your POE devices.
—If you want to play with the bypass/bridge mode, just issue the below command at a shell prompt… Final word of warning, DO NOT connect both ports to the same switch when you do this. It’s the same as doing so with a crossover cable.
smbmsg -s 0x48 -c 0x55 -o 8 0x02 0xfd 0x01 0xfe 0x00 0xff 0x88 0x77Automatically enable em0 and em1 so you can use them as normal nics:
-Drop to shell and add the following to /boot/loader.conf.local to load the smbus drivers
ichsmb_load=“YES”
smb_load=“YES”-Follow pfSense docs to modify your config.xml to with shellcmd to issue the following smbmsg command just above the </system> line…
<shellcmd>smbmsg -s 0x48 -c 0x55 -o 6 0x03 0xfc 0x01 0xfe 0x66 0x99</shellcmd> </system>
-Basic workflow for modifying your config.xml if you don’t want to read the docs, do the following via the Web UI…
1: Main Menu-> Diagnostics -> Backup & Restore Menu -> Download configuration as XML (it will download via your browser)
2: Edit the downloaded file adding the smbmsd command just above the existing line containing </system>, save the edited file
3: Click the Choose File button, select the edited file, click the Restore Configuration button
4: pfSense should restore the file and automatically rebootUpon reboot, and toward the end of the boot process you should hear a nice “click” sound from the bypass relays, enabling em0 and em1, and you should have 4 usable nics under pfSense
-
Ha. Maybe the few more upvotes I gave you.... though the level is set at 5.
You can use the shellcmd package to add that without manually editing the config.
-
@stephenw10 Just glad it worked! Roger on using shellcmd package, I have not tried it.
-
Excelent tutorial @Okijames ! I am currently running pfSense235 from a usb stick and as i can now access all ports, i will make an hdd install and follow it to configure the steelhead 250 i got.
A little off topic but this unit came with 1gb pc2-3200 ecc rec ram stick and an empty dimm slot. You have any idea of that is the max ram this can take using both slots?
cheers,
Paulo -
@pauloalb Max RAM I have tried is 4GB in my 550s using 2 2GB pc2-3200 ECC sticks. The 250/550 are based on the same "Minnow" chassis and motherboard so will likely be ok with 4GB too.
-
So this thread prompted me to dig though boxes in the o'l garage and I found a Steelhead 770. Decent specs on this puppy.
-CPU Xeon E3-1125C v2 (4core 2.5Ghz)
-RAM 4GB with 2 x 2GB DDR3 ECC sticks in two of four available slots.
-2 2.5" SATA drives (320GB 72K HDD, 160GB Intel DC S3500 SSD)
-NICS 6 Intel Gigabit NICs total
-2 "normal" NICs as Primary and Aux,
-4 (2 pairs) bypass type NICs.
-NIC bypass control is available in the BIOS plain as dayInstallation of pfSense 2.4.4 was a breeze. All 6 NICs show up, no smbus shenanigans needed.
I'm happy with my APU2 for pfSense, but this thing is just begging to replace it. Someone stop me! :)
-
@Okijames said in PfSense on a Riverbed Steelhead:
Steelhead 770
Only drawback to a box like that might be power consumption.. Its going to how much higher than your APU2?
And fans - how much louder is it going to be?
-
Yeah hard to beat the APU2 in terms of power consumption and noise.
But it's probably not that bad. I would guess ~30W. No clue about noise. I they gave the cooling setup right it need not be loud but...Steve
-
Thanks @johnpoz!
Yeah, 3-4x on the power consumption. Fans, though pretty quiet, are 100% louder than the fanless APU2.
Thinking I'll bump up the RAM and disk capacity and use it to experiment with various Container platforms.
-
Is it a SD770? From quick look those are about 50W idle - so more like 5-6x your apu2, and noise looks like about 45dba.. While not all that bad - sure isn't quiet..
-
CX-770 currently idling at ~27W, not bad. And honestly the fans are pretty quiet, faint background noise sitting right next to me on a desk. Might be near silent if I replaced them with some nice Noctuas.
Under load though, I'm sure it wouldn't be quite so pleasant.
-
2 Noctua NF-A4x20 PWM ordered. :)
-
@stephenw10 said in PfSense on a Riverbed Steelhead:
I would guess ~30W
@Okijames said in PfSense on a Riverbed Steelhead:
currently idling at ~27W
Ha.
-
I have a Riverbed 1050L with 2 InPath or 4Gbe NICs and am trying to enable them for PfSense, except the I2C Layout looks a bit different. I have been probing with i2ctools.
[root@localhost~]# i2cdetect -l
i2c-3 i2c nvkm-0000:08:00.0-bus-0005 I2C adapter
i2c-10 i2c nvkm-0000:08:00.0-aux-000c I2C adapter
i2c-1 i2c nvkm-0000:08:00.0-bus-0001 I2C adapter
i2c-8 i2c nvkm-0000:08:00.0-aux-000a I2C adapter
i2c-6 i2c nvkm-0000:08:00.0-bus-0008 I2C adapter
i2c-4 i2c nvkm-0000:08:00.0-bus-0006 I2C adapter
i2c-11 i2c nvkm-0000:08:00.0-aux-000d I2C adapter
i2c-2 i2c nvkm-0000:08:00.0-bus-0002 I2C adapter
i2c-0 i2c nvkm-0000:08:00.0-bus-0000 I2C adapter
i2c-9 i2c nvkm-0000:08:00.0-aux-000b I2C adapter
i2c-7 i2c nvkm-0000:08:00.0-bus-0009 I2C adapter
i2c-5 i2c nvkm-0000:08:00.0-bus-0007 I2C adapter
i2c-12 smbus SMBus I801 adapter at 0400 SMBus adapter <<---- I am assuming it is i2c-12 or the SMBUSHowever I found several slave addresses:
[root@localhost ~]# i2cdetect -y 12
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 19 1a 1b 1c 1d -- 1f
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2f
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- 48 49 4a 4b 4c 4d 4e 4f
50: 50 -- 52 -- 54 55 56 57 58 -- -- -- -- -- -- --
60: 60 61 -- -- -- -- -- -- -- 69 -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
[root@localhost ~]#No 0x24, but 0x48 appears with the following:
[root@localhost ~]# i2cdump -y 12 0x48
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 27 00 4b 50 XX XX XX XX XX XX XX XX XX XX XX XX '.KPXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXXFrom the command:
smbmsg -s 0x48 -c 0x55 -06 0x03 0xfc 0x01 0xfe 0x66 0x99
I gather it means write 6 Bytes to SMBUS address 0x48 with initial command byte of 0x55 the data "0x03 0xfc 0x01 0xfe 0x66 0x99"But in my case or for the RB1050L, it looks like 0x48 is only 4Bytes wide, and the command sends anywhere from 6Bytes for "Universal Mode" and 8Bytes for "Bypass/NoLine"
Can anyone that has this working please provide a dump of their 0x48 of their SMBUS so we can see what data should be there? Will the data we write show up at that address location? I don't feel comfortable writing things to random addresses that can potentially damage something.
-
For the add-on cards you're probably best off using native drivers from the manufacturer. Silicom was a popular supplier, and they offer FreeBSD drivers, see if you can find your card here...
https://www.silicom-usa.com/cats/server-adapters/networking-bypass-adapters/gigabit-ethernet-bypass-networking-server-adapters/
-
@Okijames The InPath NICs in the Riverbed 1050 which I have, are actually embedded into the motherboard.
-
@freska99 Oops, sorry memory isn't what it used to be. :)
So the problem from here is multifold. We would need to know several things, some easier than others...
-What CPU chipset / smbus controller is in use? Clues in dmesg and/or physically looking at the chips
-What's the command structure for said chipset? Find Intel docs
-Find the correct smbus address for bypass control. As you've done above, it is a moderate amount of poking/guessing.
-Guess the correct byte sequence to flip the relays. This seems pretty difficult! The numbers for the 250/550 were taken from code in another project. I have no idea how the original author figured out the correct byte sequence. Guessing he had inside knowledge.
-
FWIW I'm assuming you tried looking for settings in the BIOS. Wishful thinking, but the 570/770 do have such BIOS settings so maybe...
Or setting the nics to stop failing to bypass in RIOS?
no interface <interface-name> fail-to-bypass enable
-
Whatever you do, please find and read the chipset docs before poking around with the smb read or write commands. I somehow permanently set my 550's 1.66GHz CPU to 1.33GHz. No telling what else I could have screwed up if, for example, I randomly guessed byte sequences :)
-
@Okijames Thanks for the quick reply:
The board looks like a modified Tyan server board running with Intel ICHx SMBUS controller with Intel Xeon 2Core 1.88GHz, I was able to read from the SMBUS using ICHx drivers in both Linux and under RWEverything in Windows (although in Windows the address is 2x or double the HEX value given to the i2cdump command for some odd reason)
Yes I already tried looking in the BIOs there are only options to enable / disable the PRI/AUX Interfaces. The command 'no interface <interface> fail-to-bypass enable' has also been tried. All it does is causes the ports to go into "BLOCK MODE" so it will neither bypass nor work (under the OS it shows as Ethernet Disconnected). The BYP/BLK LED is turned on. Bypass causes the same issue with Ethernet Cable Disconnected except the relays form a physical path from one physical port to the other.
The real question I am trying to answer is what is the address of the microcontroller driving the relays. I am thinking that there might be a "signature" or "fingerprint" if someone dumped the contents of address 0x48 from the 250/550, that the contents might be similar to what I have on the 1050 so I can co-relate the correct address.
I will try taking a look inside for what specific chips are being used tomorrow. I am quite paranoid about writing anything to SMBUS especially when hardware models/revisions do not match the python script or what others are discussing, so more research is needed.