CyberSecurity Project: Transparent Filtering Bridge (+ Extras) 2.0: CLI is a UX Failure

Updated on
Image showing rear of BOSGAME MiniPC, with arrow pointing to expected re0 ethernet port on the left and arrow pointing to expected re1 ethernet port on the right.

I never intended for there to be a four week gap between the entries in this project, but there's good reason for it.

First, I passed my CompTIA Security+ exam about a week and a half after the first entry.

Second, I spent a lot of time banging my head against OPNSense/FreeBSD's Command Line Interface, which caused a lot of problems.

Let's get into those.

Table of Contents

Problem 1: Ventoy

The problem of installing operating systems has long plagued anyone who works with technology.

In the past, you would have to burn a disk image in some format onto a literal disk (a CD-ROM/DVD-ROM/etc...) or a USB drive, typically filling all or most of the storage on that disk. This was fine, because you could just buy a cheap, sub-$10 4-8 gigabyte flash drive.

These days, when the $0-10 flash drive market is dominated by 16+ GB flash drives, burning one image to a drive is a ludicrous waste of space, even if Windows ISOs balloon up to 6GB if you include all sorts of plugins and frameworks for productivity tasks.

Ventoy is software that allows your USB drive to host multiple ISOs and gives you a GUI to select which one is booted/installed.

Installing OPNSense requires downloading an image... which is confusingly labelled amd64, even though it's apparently compatible with just about anything. This is just the first of many usability issues, because most people are more familiar with 64 bit operating systems being labelled x64.

It turns out that Ventoy doesn't like the .img format, so I was looking at a potential massive progression blocker. Luckily, someone reported the latest version of the OPNSense ISO was compatible with the latest version of Ventoy, so I tried to update my USB drive.

It turned out that trying to update via the actual EXE file was impossible, so I had to install an ISO on my Ventoy USB to update my Ventoy USB.

...

Setting that aside, I then had to reboot a computer, disable secure boot on said computer, boot into Ventoy to boot the updater ISO, then reboot the PC to reenable secure boot. Which is an absurd amount of steps to accomplish a simple task, but sadly was the most straight forward part of this whole process.

Problem 2: Drivers

For the less tech savvy amongst the audience, drivers are software that take the commands a device receives from the user and translates them into instructions for the hardware. Then they translate the output of the hardware generates into forms other parts of the system and/or the user receive.

Basically, if you don't have drivers for your hardware, or they break for some reason (*cough* Windows 11 rolling back GPU drivers *cough*), things aren't going to end well.

Problem 3: FreeBSD/OPNsense CLI

The bane of modern technology is the ancient, antiquated user experience of the command line interface.

Is it incredibly fast and powerful if you know what you're doing? Yes. But if you want a summary of its flaws in the use case of "I need to install drivers to enable internet connectivity", here you go:

LinkedIn post by the author explaining usability failures in OPNSense command line shell interface.

It gets even worse from there.

So, after multiple tries and having to reload the Bing Copilot multiple times on my phone, because accessing it via browser causes it to auto-reset if you don't focus on the tab for a certain amount of time, I got it done.

I managed to update the drivers, and I was confronted by this:

Post-installation instructions from the Intel ethernet driver, telling user what lines to add to various configuration files.

After all the issues I'd run into up until this point, it should surprise no one that I took this picture. But what I didn't realize was that following these instructions wasn't the best idea. As it turns out, OPNsense doesn't recommend directly editing /etc/loader.conf.

In fact, it gives you a message when you access said file that boils down to "If you want to make changes here, go make a /etc/loader.conf.local file and make those changes there." I missed this initially, due to mental fatigue from everything I'd been through to that point. It took my hard work being wiped by rebooting the miniPC to make me realize there was an issue there.

Once I figured out my issues there, I ran into an issue that I hadn't expected while trying to setup the bridge: the ethernet port numbers were reversed.

Image showing rear of BOSGAME MiniPC, with arrow pointing to expected re0 ethernet port on the left and arrow pointing to expected re1 ethernet port on the right.

How did I discover this, you might ask?

Well, I was trying to connect to the webGUI via ethernet connection from what I thought was re1 to a laptop, and nothing I did was working. Initially, I believed it to be the fault of a particularly old, janky looking ethernet cable, but swapping it out for a shorter, but better looking cable didn't solve the problem. I checked the port status for re1 via ifconfig, but the status was down, which was confusing, because I could see the activity light on the port flashing like crazy.

After way too much time getting nowhere, I decided to check re0... and saw the status was up.

Image showing rear of BOSGAME MiniPC, with arrow pointing to re1 ethernet port on the left and arrow pointing to re0 ethernet port on the right.

This is apparently a non-infrequent occurrence, and highlights yet another weakness of command line interfaces. A basic GUI that captured and presented network activity would've alerted me to this issue far sooner.

Once I was past this hurdle, I could log into the webGUI and begin configuring the transparent filtering bridge.

Problem 4: Did Anyone Try This on Dual Port Devices?

Following the instructions to initialize the transparent filtering bridge was simple and straightforward, and having set a management IP address on the bridge, I connected it to my router and modem. I got my internet... for a few seconds before the Suricata IPS crashed.

It took me a while to figure out what was going on, but since I had access to the webGUI via ethernet, I could look at the crash dumps and find key phrases. The specific fatal error that came up led me to an OPNSense forum thread that gave me the lead that Suricata might be the culprit.

With that out of the way, I hooked things up back up, and got the transparent filtering bridge back up. Just with a new problem - I couldn't access the webGUI. I had access to the console, because I had the miniPC plugged into a monitor and connected to a wireless mouse and keyboard. But without webGUI access, I couldn't update the OPNSense software - which is a major problem for security, even setting aside the fact that several patches were released between when I downloaded the ISO and when I installed it on the miniPC.

In fact, this seems to be a fairly common issue with OPNSense and transparent filtering bridges:

It turns out that I wasn't the only one who saw the Dave's Garage video that kicked this project off and wanted to setup their own transparent filtering bridge, only to run into the same type of problem.

Unfortunately, this is an impassable roadblock for me, at least at the moment. Attempting to use the miniPC's wireless connection as the management interface is a no-go, for two important reasons:

  1. I couldn't connect it to my home network at all, which is why I had to install ethernet drivers off a USB.
  2. For some reason, the command ifconfig [WiFi interface] down completely removed the ability to use the device.

That's right, I have a wireless networking device that I cannot use because shutting it down apparently wiped the association to the drivers it was using.

FreeBSD/OPNSense is wonderful like that.

Theoretically, adding a third ethernet port via USB might solve the problem. The widespread nature of the problem and other people's noted failures with that solution make me hesitate. On one hand, I'm not particularly thrilled to spend more money on this project to solve a problem that is not my fault. On the other, it's at least a general purpose device I can use in other situations if it fails to solve the problem.

What's Next?

Well, having submitted a bug report that will (hopefully) lead to this problem being solved, I'm pivoting focus.

Not to a new project, but to the inevitable next step: making firewall and IPS rules.

 

Related posts