Choosing a firewall appliance for a security lab

A security lab needs a network that can safely contain what you put in it: malware samples, vulnerable VMs, IoT devices under test and forensic workstations that must never talk to each other by accident. The heart of that network is a firewall that routes between segments, and a switch that enforces them.

This guide covers the hardware choices: what to look for in a firewall appliance, how to plan VLANs on a managed switch, and how to capture traffic properly.

Lab segments first, hardware second

Size the hardware from the segments you need, not the other way around. A typical practitioner lab:

The rules are what make this a lab and not a flat network: default deny between VLANs, explicit allows, and logging on every inter-VLAN rule that touches DETONATION or IOT-DUT.

What to look for in a firewall appliance

Most labs run an open-source firewall distribution (pfSense, OPNsense) or a Linux box with nftables on a small x86 appliance. The hardware questions are the same.

Network interfaces

The NIC chipset matters more than CPU clock speed:

• Intel NICs (for example the i210/i211 at 1 Gb/s, i225/i226 at 2.5 Gb/s, X710 family at 10 Gb/s) have mature drivers on FreeBSD and Linux. Early i225 steppings had link stability problems; check the revision on used or cheap units.
• Realtek NICs are common in low-cost boxes; driver support on FreeBSD-based firewalls has historically been weaker.
• Count ports for your topology. With 802.1Q tagging, two ports (WAN + trunk to the switch) are enough for many VLANs; extra ports let you keep DETONATION on a physically separate link.

CPU features

• AES-NI (or equivalent) is essential if you run IPsec or WireGuard/OpenVPN tunnels at reasonable speed. WireGuard's ChaCha20 does not use AES-NI but benefits from vector instructions.
• Cores matter for IDS/IPS: Suricata scales with threads; a 4-core modern low-power CPU is a comfortable baseline for gigabit inspection with a moderate rule set.
• Virtualization support (VT-x/VT-d, AMD-V/AMD-Vi) if you plan to virtualize the firewall or pass NICs through to it.

Memory and storage

• 8 GB RAM is comfortable for a firewall with an IDS and a proxy; rule sets and flow tables grow quickly.
• Prefer an SSD with decent endurance over eMMC or USB sticks if you log locally or run a proxy cache.
• ECC RAM is nice to have for an always-on box, rarely a hard requirement in a lab.

Firmware and management

• Check that the BIOS/UEFI receives updates and supports Secure Boot where your OS can use it.
• Some appliances include out-of-band management; if so, isolate it on the MGMT VLAN and change default credentials immediately.
• Fanless units are quiet but need airflow; thermal throttling silently reduces throughput under IDS load.

Managed switch requirements

A lab switch needs, at minimum:

• 802.1Q VLANs with tagged trunk and untagged access ports.
• Port mirroring (SPAN) for occasional captures.
• Management on a dedicated VLAN with HTTPS and SSH, and the ability to disable plain HTTP and Telnet.
• Port security features such as limiting MAC addresses per port, and DHCP snooping if your devices under test misbehave.
• PoE if you power access points, cameras or IoT devices under test.

Label ports physically. In a lab, the most common segmentation failure is a device plugged into the wrong port.

Capturing traffic: TAP versus SPAN

Types of TAP to know:

• Passive fibre TAPs split light and need no power.
• Passive copper TAPs work for 10/100 Mb/s; gigabit copper requires an active TAP that regenerates signals (choose one that fails open so the link survives power loss).
• Aggregating TAPs merge both directions onto one monitor port; they can drop packets if the combined rate exceeds the monitor port speed.
• Throwing star-style passive LAN taps are cheap and useful for 10/100 IoT devices.

For continuous monitoring, feed the TAP into a sensor running Zeek and Suricata, and store full packet capture for a rolling window.

A simple ring-buffer capture on a sensor interface, rotating files every 100 MB and keeping the last 50 (lab.pcap00 to lab.pcap49):

sudo tcpdump -i enp3s0 -s 0 -w /data/pcap/lab.pcap -C 100 -W 50 -Z tcpdump

An nftables sketch for a Linux-based lab router

If you build the firewall on Linux, the policy for the segments above looks like this (interface names are examples):

table inet lab {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    ct state invalid drop

    # Trusted workstation may reach the lab on admin ports
    iifname "vlan20" oifname "vlan30" tcp dport { 22, 3389, 5985, 443 } accept

    # Trusted and lab segments go out to the internet
    iifname { "vlan20" } oifname "wan0" accept

    # Detonation and forensics never leave their segment
    iifname { "vlan40", "vlan60" } log prefix "lab-deny " counter drop
  }
}

Keep management interfaces (vlan10) out of the forward chain entirely and handle them in the input chain with an allowlist.

Buying checklist

• Enough NICs of a well-supported chipset, at the speed you actually need.
• AES-NI and enough cores for VPN and IDS workloads.
• At least 8 GB RAM and an endurance-rated SSD.
• Firmware that is still updated by the vendor.
• A managed switch with 802.1Q, SPAN, management VLAN and PoE if needed.
• A TAP for any link you want to capture reliably, especially for evidence or detection engineering.

A well-segmented lab is what lets you detonate, break and investigate without risking the rest of your network, and it is mostly a matter of discipline supported by modest hardware.