title: Linux on the Barracuda CloudGen Firewall F380 Revision B
description: My new main router.
created: 10/02/2025
slug: f380b
---
While idly browsing eBay, I came across Barracuda Networks "firewall" devices, mysterious boxes with lots of (fairly low-speed) network IO and basic general-purpose-computer IO (USB and VGA). It transpired that Barracuda is primarily in the business of selling expensive software licenses to people who for some reason don't want to use open-source software, and that the mysterious boxes were actually rebadged x86 machines from various "network appliance" vendors. The [F180A](https://campus.barracuda.com/product/cloudgenfirewall/doc/169426005/f180-and-f183-revision-a) I was considering originally has an outdated Atom CPU[^1] and apparently an integrated WiFi card, which was not that interesting, but further searching turned up the [F380B](https://campus.barracuda.com/product/cloudgenfirewall/doc/93880710/f380-revision-b/) at a very low price (£37). Barracuda do not document this, but as far as I can tell it's actually an [Aewin SCB-1723](https://www.aewin.com/products/scb-1723/), with "recent" (2017) Intel CPU compatibility[^2] and a low-end Celeron in it - and, in their version, two SFP+ ports driven by an [X710](https://www.intel.com/content/www/us/en/products/details/ethernet/700-network-adapters/x710-network-adapters/docs.html)! I clearly had to get one to stop my overtaxed access point from also serving as a router.
The public internet doesn't seem to have thorough details on the internals, so here you go:
```
root@archiso /tmp # lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Vendor ID: GenuineIntel
Model name: Intel(R) Celeron(R) G4900 CPU @ 3.10GHz
CPU family: 6
Model: 158
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
Stepping: 11
CPU(s) scaling MHz: 32%
CPU max MHz: 3100.0000
CPU min MHz: 800.0000
BogoMIPS: 6202.33
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0930:6545 Toshiba Corp. Kingston DataTraveler 102/2.0 / HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
```

::: captioned src=/assets/images/f380b_hw.jpg
This is the only picture of the internals on the internet (that I know of), probably because these are rare and I had to undo about twenty screws to get this far. I assume this was done to spite maintenance technicians.
:::
::: captioned src=/assets/images/f380b_psu.jpg
It uses some kind of off-the-shelf nonredundant low-quality power supply, but the interfaces look standard so I guess you could replace it if you wanted to.
High-speed networking is on a separate proprietary-form-factor daughtercard with, for *some* reason, another PCB providing a right-angle connection.
:::
::: captioned src=/assets/images/f380b_cpu.jpg
You can just about see the CPU socket under the heatsink and airflow guides. There's also a free RAM slot.
:::
The four SATA ports here and the extra SATA power available from the PSU mean that, if you wanted to and could print or otherwise fabricate more drive mounts, you could use this as a very janky four-drive NAS. I was hoping for a free mini-PCIe or M.2 slot, but it seems that all the lanes are in use by the PCIe switches for the front-panel NICs and the X710. Also, you'll note from the `lscpu` output that this CPU is vulnerable to several side-channel attacks which it's software-mitigating: I recommend you disable mitigations because Skylake derivatives are quite badly affected performancewise, and if you're running untrusted code on a router something has clearly gone very wrong some time ago.
I do not have a VGA or serial console adapter, but it has an Ethernet port and USB and boots USB sticks by default, so it was a simple matter to boot an [Arch installer image with SSH configured](https://wiki.archlinux.org/title/Install_Arch_Linux_via_SSH#Using_a_single_USB_flash_drive) and then write OpenWRT to the internal storage. Unfortunately, this did not actually work: it imaged fine but the network ports failed to come up. Fortunately, it turned out that the problem was simply OpenWRT only enabling some of the ports, and in a weird order - it wanted 5 as LAN and 6 as WAN, in the numbering on the front panel.
It is very loud by default - the fan curves are set aggressively (8000 RPM!), presumably for datacentre use. If you install the drivers for the NCT6791 chip, Linux enumerates the fans through sysfs; I have a hacky script which adjusts the PWM operating points down. There also is an LCD panel with some buttons on the front, which I wanted to use. It turns out that the code for this is all very 1990s; I eventually managed to get everything to work by extracting the `lcd4linux` binaries and configuration from the official firmware[^3] [ISO](https://dlportal.barracudanetworks.com/download/6120/GWAY-9.0.4-0097.iso). It might be possible to use `lcdproc`, but I wasn't able to port the configuration properly.
It's currently in service as the core router for my home network, running horribly underutilized because I only have gigabit internet service and [SQM](https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm) isn't particularly heavy for a "real" processor.
[^1]: Barracuda doesn't document it, but one seller says it's a [C2358](https://www.intel.com/content/www/us/en/products/sku/77978/intel-atom-processor-c2358-1m-cache-1-70-ghz/specifications.html). Note that this generation, if maybe not this product, is vulnerable to the [AVR54](https://www.servethehome.com/intel-atom-c2000-c0-stepping-fixing-the-avr54-bug/) bug.
[^2]: Aside from BIOS compatibility, it might be possible to put an i9-9900K in there, which would be very funny. The [CC150](https://www.tomshardware.com/news/intel-cc150-cpu-specs-benchmark-results), which is a very power-efficient 8C/16T CPU, would probably be nice and not particularly unreasonable.
[^3]: The LCD control stack is so cursed. A systemd service invokes an init script which regex-substitutes a config file and fudges CLI arguments for a C program which runs a GUI in a programming language embedded in `lcd4linux` which calls out to some shell scripts. They kept enough of the original pieces that I could cut out several parts though.