When my network needs a new router, I usually reach for OpenWRT before OPNsense. They’re both extremely capable edge routers, especially when deployed as a VM. However, once I start stacking interfaces, VLANs, and rules, I find myself needing to draw out the topology to remember which networks can reach which others.

It’s just too much complexity when all I need is a lab router.

IPFire’s color-coded RED, GREEN, ORANGE, and BLUE zones offer a simpler way to picture those boundaries. My spare ZOTAC mini PC had two Ethernet ports and an Intel Wi-Fi card, giving each network its own physical interface and making the whole layout far easier to work with.

The ZOTAC gave me a tangible network boundary

Two Ethernet ports gave my experiments their own corner of the network

My little ZOTAC Mini PC was sitting around collecting dust after I tried to make it into a hypervisor. With IPfire, it finally had a job that suited its hardware and, let’s face it, fairly mediocre Celeron processor.

Its dual NICs, Intel Wi-Fi card, 8GB of RAM, and SSD gave me everything I needed to turn it into a router appliance.

IPFire asked me to choose a network layout during its initial setup, and I chose GREEN + RED. This is where the colors really started to click for me. Each color comes with not only a type of network, but a specific job. This gave me a useful network map before I’d even written a single firewall rule.

During setup, IPFire also asks which network interface I want to assign to which color. It lists the available adapters by their MAC addresses.

Looking at the back, I had a 50/50 chance the Network Interface Card (NIC) on the right-hand side would be the RED network, connected to my LAN, and the remaining NIC would be the GREEN network. After a little trial and error consisting of plugging my laptop into each port with a crossover cable, I discovered that, of course, I guessed wrong.

I ended up with the RED network assigned to the left-hand NIC, and the GREEN network to the right. I set RED to get its address via DHCP from my edge router, like any device on my LAN. GREEN got the fixed address of 10.77.50.1, and I enabled IPFire’s DHCP server to hand out lab addresses from 10.77.50.100 to 199.

The wired section of the lab was now alive, and each side had a clear job. Eventually, I would add a BLUE wireless network, but first I needed to isolate the lab network properly.

My lab wasn’t isolated until I wrote the right rule

The first ping test found a route back into my home network

The laptop, connected to GREEN, had an address, DNS worked, and websites loaded. Then I pinged a device on my home LAN only to discover it answered back with a friendly ICMP Echo Reply. As it turns out, IPFire’s default firewall settings meant my experiments could still wander next door.

The explanation was straightforward. GREEN could send traffic through RED, and my home network sat on that upstream side. Giving the lab a different subnet wasn’t enough to keep the traffic away from the rest of my network.

Luckily, IPFire makes creating firewall rules super easy. I created a DROP rule that targeted 192.168.1.0/24 across all protocols. Setting the source to Standard networks → GREEN put the rule under Forward Firewall Access, where traffic passing through the router belonged. After saving and applying the rule, I repeated my earlier tests:

1. The home network device stopped answering pings.
2. 1.1.1.1 still replied, showing that public internet access hadn’t been broken by the rule.

That was the boundary I needed. The lab could use my internet connection without getting free access to everything on the upstream network.

OS

Standalone Linux-based firewall distribution

Key highlights

Color-coded network zones, configurable firewall rules, traffic graphs, and add-on packages

BLUE turned the spare Wi-Fi card into a second lab

The access point worked once I stopped trusting automatic channel selection

The ZOTAC’s Intel Wireless 3165 gave me a way to bring phones and other wireless test devices into the lab. First, I checked its capabilities to confirm it supported access point mode:

iw list | grep -A 12 'Supported interface modes'

The hardware supported not only AP mode, but monitor and P2P client as well.

Back in the console setup, I changed the network type to GREEN + RED + BLUE and assigned the wireless adapter to BLUE. I gave the BLUE interface the IP 10.77.60.1/24 and enabled DHCP for addresses from 10.77.60.100 to 199. I then installed the hostapd access point add-on through IPFire’s package manager.

The new wireless configuration page let me name the network IPFire-Lab-Blue, set the country code, and pick the wireless mode: IEEE 802.11an/gn 20 MHz. I set the band to 5 GHz with an auto-selected channel, saved, and started the wireless access point.

For about 10 glorious seconds, the service reported RUNNING, then stopped before my phone could even find it. I had to dive into the logs to find the reason why the AP kept getting disabled after starting:

grep -iE 'hostapd|blue0|iwlwifi' /var/log/messages | tail -n 60

The reason for this failure turned out to be incredibly interesting. The automatic channel selection had decided that the 5 GHz channel 52 was the ideal place to broadcast.

Channel 52 is also used by some military, air traffic control, and weather radar systems. That means the AP must take one minute to check for these before broadcasting, known as Dynamic Frequency Selection (DFS).

That delay was causing hostapd to abandon startup and stop the service from running. Switching to 2.4 GHz with a fixed channel brought the network up straight away. My phone connected, and IPFire’s color model had gained another useful boundary.

I opened exactly one door from BLUE to GREEN

A local dashboard loaded on my phone while the rest of the wired lab stayed closed

My phone joined BLUE and was able to reach my local LAN. That route was closed for GREEN, but wireless clients needed their own rules. I added another DROP rule targeting 192.168.1.0/24, this time with Standard networks → BLUE as the source. After applying, the edge router stopped answering pings, while outside internet access remained.

Next came testing some more defined boundaries. I spun up a VM on my laptop and installed the Homarr dashboard via a Docker container. Since the VM’s network was in bridged mode, it received an IP address 10.77.50.101 from the GREEN DHCP server.

The phone now couldn’t ping it, which was fine, but I wanted access to the dashboard without giving wireless devices access to the entire subnet.

I created an ACCEPT rule from BLUE to 10.77.50.101 and limited access to TCP destination port 7575. Opening http://10.77.50.101 on the phone brought up the dashboard’s login screen, but trying to ping the same IP failed. Ping failed simply because I’d allowed the dashboard’s TCP traffic, and not ICMP.

I now had a useful and targeted arrangement for testing. Wireless devices could reach a single service I designated through firewall rules, while the rest of the home and GREEN LAN stayed off-limits.

I could see what the firewall was doing

Connection details and graphs are what make IPFire so good for testing

Once the boundaries worked, I wanted to see what was actually crossing them. IPFire’s Connections page is a powerful way of seeing the source and destination addresses of active connections, including geolocation.

I wanted to test this functionality, so I used a website that wouldn’t take the scenic route through a CDN — the University of Ghana’s website at https://ug.edu.gh. The Ghanaian flag appeared in my Connections output, which gave me a useful policy test.

I temporarily blocked traffic from the lab to the entire country via a geoblocking rule, and the website timed out. I removed the rule afterward, having proved the behavior I needed to test.

IPFire’s graphs also give me a broad view. Separate GREEN and BLUE traffic charts let me look at and compare activity on the wired and wireless networks. The firewall-hit graph also shows every dropped or rejected packet over time, and hardware graphs keep an eye on system temperatures and resource usage.

These views help me to inspect specific tests, and the graphs show all the surrounding activity. They also look fantastic, which certainly doesn’t hurt.

IPFire earned its place despite the gotchas

OpenWrt’s still my favorite, but IPFire fits this physical lab

IPFire makes networking simple, but it still comes with plenty of installation and setup gotchas. Probably one of the best (and ironic) examples of this was not being able to access IPFire’s own website through the router.

www.ipfire.org returned SERVFAIL when the upstream edge router’s DNS resolver failed to complete DNSSEC and validate the domain. Switching IPFire to 1.1.1.1 fixed that issue, but it’s still an annoying complexity in what should otherwise be a fairly straightforward setup.

Still, the ZOTAC has now given me a wired lab, a separate wireless zone, specific exceptions between them, and extremely useful data via graphs.

I’d still reach for OpenWRT when I need the flexibility. For this box, though, IPFire’s colors gave every interface a defined job and made the rules far easier to understand. The setup took some patience, but in the end, I have a lab I understand well enough to start breaking things in it.