Skip to main content
Advanced Engineering

Firewall Engineered at the Packet Level

Firecradle operates where most consumer routers don't - every packet is matched against conntrack state, evaluated through a single unified nftables ruleset, and optionally handed to an inline Suricata engine for signature inspection, all before it's allowed to leave the box. A manifest-diff reconciler for routing and an atomic, single-transaction apply for the firewall table mean a config change is either fully applied or not applied at all - never half of both.

100k+ PPS
Rule evaluation throughput
<10ms
Rule evaluation latency
10,000+
Concurrent tracked connections
AES-256
IPsec / OpenVPN tunnel cipher
Independent by Design

Every Component Stands Alone

The firewall/NAT engine, the routing layer, and the VPN stack are fully independent subsystems, each rendering its own config and reconciling its own state. Deploy what your environment needs - skip what it doesn't. No monolithic dependencies, no forced lock-in.

Core Enforcement

Firewall & NAT Engine

The nftables rule compiler and NAT compiler produce independent output, merged by a shared reconciler into one ruleset and applied as a single atomic transaction. Runs without touching routing, VPN, or shaping state.

Path Selection

Routing & Multi-WAN

Static routes, policy-based routing, gateway groups, and optional FRR dynamic routing (BGP/OSPF/RIP) reconcile against a persisted manifest - never touching a route it doesn't own, never flushing the system's main table.

Secure Access

VPN & Tunnel Layer

WireGuard, IPsec, and OpenVPN each manage their own keys, proposals, and processes independently. Every tunnel inserts only a tagged firewall rule to permit its listen port - it never edits the ruleset directly.

Four Independent Building Blocks
Filter

Stateful nftables rules - zone, protocol, port, schedule. Single ruleset, atomic apply.

Route

Policy-based routing, multi-WAN gateway groups, optional BGP/OSPF/RIP via FRR.

Shape

tc/HTB/HFSC/cake queue trees. DSCP + priority marking, VoIP/gaming presets.

Tunnel

WireGuard, IPsec, or OpenVPN - each independent, each auto-permitted by the firewall.

HA PairOptional Add-On

Combine two appliances as an active/passive VRRP pair. The standby mirrors config via a scoped REST sync and keeps session state current via conntrackd - so a failover doesn't just move an IP, it keeps existing connections alive.

PRIMARY+STANDBY
Every rule enforced on-box, at line rate - no cloud round-trip for a verdict

Firecradle targets 100k+ packets-per-second rule evaluation with sub-10ms latency, and inline IPS scanning happens on the same box, in the same pass, before the packet leaves. There's no redirecting traffic through a third-party scrubbing center to get an inspection verdict.

Core Architecture

The 8-Phase Packet Pipeline

Every packet - inbound, outbound, or forwarded - passes through a deterministic eight-phase pipeline, with destination NAT applied before routing and source NAT applied after filtering. No shortcuts, no silent drops.

01

INGRESS

Every packet lands on a physical or bonded NIC and enters the kernel netfilter prerouting hook before any routing decision is made - the earliest point in the stack where Firecradle can see the traffic at all.

01
02

CONNTRACK

The connection-tracking subsystem hashes the packet's 5-tuple and checks it against the kernel conntrack table. A hit classifies it ESTABLISHED or RELATED; a miss marks it NEW; malformed packets are flagged INVALID.

02
03

DESTINATION NAT

Still in the prerouting hook, DNAT rewrites the destination address for port-forwards and 1:1 mappings - before the routing decision, so a port-forwarded packet is routed and filtered against its rewritten (internal) destination, not the one it arrived with.

03
04

ROUTE

A routing decision selects the egress path based on the post-DNAT destination - the system routing table, a policy route chosen by source/destination/mark via ip rule, or a multi-WAN gateway group balancing or failing over across links.

04
05

FILTER

The packet is evaluated against the single unified nftables table (table inet firecradle) - input, forward, or output chain, matched on zone, protocol, port, and conntrack state in one pass.

05
06

INSPECT

Rules that call for deep inspection hand the packet to Suricata over an NFQUEUE verdict channel. Its signature engine checks payload against ET Open, ET Pro, VRT, or custom rule sets and returns a verdict.

06
07

SOURCE NAT

In the postrouting hook, after filtering has accepted the packet, SNAT/masquerade rewrites the source address for outbound traffic - compiled into the same ruleset as the filter rules, applied atomically.

07
08

EGRESS

The packet reaches postrouting and, if a shaper rule matches, is classified into a queue - DSCP-marked, priority-tagged, and scheduled through HTB, HFSC, or cake - before it leaves the interface.

08
Rule Architecture

netfilter/nftables - One Unified Ruleset

Firecradle runs nftables only - no iptables. Filter and NAT rules both live in a single named table, table inet firecradle, so the same ruleset can be reasoned about, tested, and applied as one object instead of two.

A rule engine compiler and a NAT compiler produce their output independently, but a shared reconciler merges both into one ruleset before every apply - avoiding a class of bug where the NAT compiler's own flush could clobber rules the filter compiler had just written.

Ruleset Apply Stack
Rule Engine + NAT Compilers
Reconciler - merges filter + NAT
nft -f - (atomic transaction)
table inet firecradle (single flush + rebuild)
prerouting → input/forward → output → postrouting
Linux kernel nf_tables hooks
Conntrack States - Evaluation Order
StateHow It WorksPriorityRule Cost
ESTABLISHEDPacket matches an existing tracked flow. Fast-paths through the ruleset without a full rule scanFastestFast-path match
RELATEDBelongs to a helper-tracked secondary flow of an existing connection (e.g. an FTP data channel, an ICMP error)FastHelper-assisted match
NEWFirst packet of a flow with no conntrack entry yet - evaluated against the full ruleset, including any DPI hand-offStandardFull rule evaluation
INVALIDDoesn't fit any known connection - out-of-window TCP, malformed headers, or spoofed trafficRejectDropped immediately
Two Compilers, One Ruleset: How the Reconciler Closes the Gap

The rule engine and the NAT engine compile independently, but a shared reconciler merges both outputs before every apply, so a single nft -f - transaction writes one table inet firecradle with every filter and NAT chain together - never two separate flushes racing each other.

Routing Architecture

Never Flush What You Don't Own

Firecradle re-renders the full desired routing state on every change and applies it as a single, idempotent pass. No incremental patch queue, no partial state to reconcile by hand - and no risk of wiping a route it doesn't own.

Manifest-Diff Apply
Route Reconciliation

The routing module keeps a manifest of every route it manages. On each apply, it diffs the desired state against that manifest and issues ip route replace for changes and ip route del only for routes it owns by key. It never runs a full table flush against main - that table also holds routes owned by DHCP and the OS.

  • Desired state loaded from config, keyed by address family + table + destination
  • Manifest at /etc/firecradle/routes.json tracks every previously-applied, Firecradle-owned key
  • Idempotent ip route replace re-converges without unnecessary route flaps
  • Default-route ownership assigned to a single module, preventing two subsystems from racing to program 0.0.0.0/0
  • The same manifest-diff pattern protects VLANs and bonds - reapplying a config is a no-op update, not a rebuild
On-Box Enforcement

Beyond Packet Filtering - The Appliance Actively Defends

A cloud-redirected UTM stops at forwarding your traffic somewhere else for inspection. The Firecradle appliance is a full compute node that scans, monitors, and fails over on its own. It runs inline signature inspection in the same pass as the rest of the ruleset. It watches every WAN link's health continuously. It keeps sessions alive through a node failure - not a guess about uptime.

<10ms
Rule evaluation latency
100k+ PPS
Rule throughput target
20% / 40%
Gateway loss thresholds
Air-gap
No internet required for enforcement
Security

Inline IPS/IDS Threat Scanning

Rules that call for inspection hand the packet to Suricata over an NFQUEUE verdict channel before it ever reaches its destination - signature matches against ET Open, ET Pro, VRT, or custom rule sources, all on the same box.

Change Safety

Config Validated Before It Applies

Every ruleset change is syntax-checked (nft -T) and every IDS/IPS config is validated (suricata -T) before it ever touches a live interface. A bad change is rejected outright - it never becomes a bad reload.

Multi-WAN

Gateway Health Monitoring & Failover

Each WAN gateway is probed continuously (ping/fping, ~5s interval), tracking loss percentage and RTT. Warn/alert thresholds default to 20%/40% loss and 300ms/500ms latency, driving automatic failover before users notice.

Performance

Line-Rate Local Rule Evaluation

Rule matching happens on-box, targeting 100k+ packets-per-second with sub-10ms evaluation latency - no redirecting traffic through a third-party scrubbing center to get an enforcement decision.

Resilience

On-Box Enforcement, No Cloud Dependency

The ruleset, IPS engine, and VPN termination all run locally. Losing internet connectivity doesn't disable protection - it just removes remote management until the link returns.

Reliability

Safe Reconciliation, Never Clobbers System State

The routing manifest-diff only deletes routes it manages by key - DHCP and OS-installed routes are untouched. The firewall table applies as one atomic transaction - always fully old or fully new, never a partial ruleset.

Firecradle Appliance vs. Cloud-Redirected UTM - Capability Matrix
CapabilityFirecradle ApplianceCloud-Redirected UTM
Inline IPS/IDS scanning✓ Suricata engine runs on-box~ Traffic redirected to a scrubbing center
Config apply safety✓ Validate-then-atomic-apply (nft -T)- Vendor-managed, no local dry-run
Gateway/multi-WAN failover✓ Local active probes (20%/40% loss)~ DNS-based failover - minutes, not seconds
VPN tunnel termination✓ WireGuard/IPsec/OpenVPN, terminated local- Traffic hairpins through a vendor PoP
Air-gap / offline enforcement✓ Zero internet required for enforcement✗ Requires continuous cloud connectivity
HA failover with session continuity✓ VRRP + conntrackd - sessions survive~ Vendor-managed, opaque failover behavior
Traffic shaping enforcement✓ On-box tc/HTB/HFSC/cake queue trees- Best-effort, no local queue control
Route/rule change safety✓ Manifest-diff - never touches unmanaged state- Opaque, vendor-controlled apply
Change Safety

Atomic Ruleset Apply - No Partial State

When Firecradle pushes a firewall or routing change, it doesn't patch the running configuration rule-by-rule. It renders the complete desired ruleset - filter and NAT chains merged by the reconciler - and applies it as one transaction. The kernel accepts the entire new table or keeps the old one; there is no window where half the rules are old and half are new.

The same discipline applies to routing: the reconciler diffs desired routes against a persisted manifest and only touches the keys it manages. An anti-lockout rule is prepended ahead of the default-drop policy on every apply, so management access survives even a broken ruleset push.

Single nft -f - transaction swaps the whole ruleset - old or new, never a mix
Anti-lockout rule always evaluated before the default-drop policy
Manifest-diff apply for routes - only Firecradle-managed keys are touched
Config validated (nft -T, suricata -T) before it's ever applied to a live interface
Apply Safety Comparison
Naive per-rule apply (add/delete one at a time)Partial-state window
A rule removed before its replacement is added briefly opens or blocks the wrong traffic
Firecradle atomic transaction (single flush + rebuild)No partial state
The entire ruleset swaps in one kernel transaction - always fully old or fully new
Reconciliation Building Blocks
routes.json
Manifest
Tracks every Firecradle-managed route key
nft -f -
Atomic Transaction
One flush + rebuild per apply, filter+NAT merged
ip rule
Policy Routing
Custom tables by source/dest/fwmark/interface
Conntrack Hash Table

O(1) Flow Lookup - Regardless of Table Size

Every active connection is tracked in the kernel's conntrack table, keyed by a hash of its 5-tuple - protocol, source/destination address, source/destination port. Tested at 10,000+ concurrent connections, a lookup to determine whether a packet belongs to an existing flow is a constant-time hash operation regardless of how many connections are active.

Conntrack isn't a Firecradle-proprietary store - it's exposed and manageable through the standard Linux conntrack tool, so anything the ruleset does with connection state is independently verifiable from the command line.

Hash of the 5-tuple keys every tracked flow - O(1) lookup regardless of table size
Tested at 10,000+ concurrent active connections during load testing
Inspectable with the standard CLI - conntrack -L -o extended, conntrack -S
Per-flow counters: packets in/out, bytes in/out, established_at, last_seen
Inline Inspection Pipeline

Single-Pass DPI - No Second Scan

Deep packet inspection happens inline, in the same pass as the rest of the ruleset evaluation - not as a separate scan after the fact. When a rule calls for inspection, the packet is handed to Suricata and a verdict comes back before it's allowed to continue:

Per-Packet Inline Pipeline
Packet arrives, conntrack state resolved (NEW/ESTABLISHED/RELATED/INVALID)
nftables rule match - protocol, zone, port, state
NFQUEUE hands the packet to Suricata for inline inspection
Signature match against ET Open / ET Pro / custom rule sets
Verdict returned - accept, drop, or alert logged to eve.json
IDS (detection-only, af-packet) or IPS (inline, NFQUEUE) - same engine, different mode
suricata-update pulls and refreshes rule sets without a full reinstall
Per-signature tuning: suppress, threshold, or disable by SID/GID/rev
Conntrack State per Flow - O(1) Bucket Lookup
Flow 0
E
Established
↑ fast-path
Flow 1
N
New
↑ full eval
Flow 2
E
Established
↑ fast-path
Flow 3
R
Related
↑ fast-path
Flow 4
I
Invalid
↑ drop
···
Flow N−1
E
Established
↑ fast-path
Flow N
N
New
↑ full eval

In steady state, most tracked flows sit in ESTABLISHED and skip full rule re-evaluation - only NEW flows and the rare INVALID packet pay the cost of a full ruleset pass.

5-Tuple → Conntrack Hash → Flow Entry
5-Tuple
──── hash ──→
proto / src / sport / dst / dport - identifies a single flow
Hash Function
Deterministic
Fast, uniform distribution over the tuple
Hash Bucket
Table Slot
O(1) average-case lookup
Flow Entry
conntrack record
State, counters, timestamps - queried via conntrack -L

Firecradle exposes this through the standard Linux conntrack tool - conntrack -L -o extended for a live dump, conntrack -S for aggregate stats, conntrack -D to terminate a specific flow by its 5-tuple.

High Availability

VRRP Failover + Multi-WAN Resilience

Firecradle pairs run active/passive - not a complex multi-node consensus cluster. A virtual IP fails over via VRRP in one direction; multiple internet connections fail over, or load-balance, independently in the other.

VRRP Failover Flow
Primary Node - MASTER
Owns the virtual IP(s) and advertises VRRP heartbeats on the configured interface
Secondary Node - BACKUP
Listens for VRRP advertisements and tracks peer health continuously
Missed Advertisements
When advertisements stop arriving, the backup node transitions from BACKUP to MASTER (~2 sec, automatic)
VIP Takeover
The new primary claims the virtual IP(s) and begins answering traffic immediately
conntrackd State Sync
Established connections are continuously synced between nodes, so active sessions survive the failover
Active/Passive, Not Consensus

A two-node CARP-style design, not an N-node Raft cluster - a simpler, more predictable failure mode for a firewall pair.

Scoped Config Sync

The primary pushes a config bundle to its peer over an authenticated REST call, scoped to selected categories (rules, NAT, aliases, certs, users). Interface and HA-identity settings are excluded, so a sync can't clobber peer-local identity.

Manual or Automatic

Trigger a failover on demand for maintenance, or let VRRP's own advertisement timing handle it automatically.

Sessions Survive

conntrackd state sync means an in-progress connection doesn't need to restart from scratch after a failover.

Multi-WAN Gateway Monitoring - Failover or Load-Balance Across Links
Gateway Health → Route Reconvergence
WAN Gateways Monitored
Each configured gateway is probed continuously (ping/fping) to a monitor_ip on roughly a 5-second interval.
Loss & Latency Tracked
Packet loss percentage and average RTT are recorded per gateway on every check.
Threshold Breach
Warn thresholds default to 20% loss / 300ms latency; alert thresholds default to 40% loss / 500ms latency.
Gateway Group Trigger Fires
member_down, packetloss, latency, or loss_or_latency triggers re-evaluate the group.
Routes Reconverge
The default route (or a policy route) is re-pointed to a healthy gateway via an idempotent replace - or, for a weighted single-tier group, traffic spreads across multiple WANs via ECMP.
Active Health Probing

Continuous ping/fping checks, not a passive link-up/link-down signal - a WAN can be up but still failing.

Two-Stage Thresholds

Separate warn and alert thresholds (20%/40% loss, 300ms/500ms latency) avoid flapping on a single bad ping.

Failover or Load-Balance

A multi-tier gateway group fails over; a single-tier weighted group load-balances across WANs simultaneously via multipath routing.

Never Touches System Routes

The reconciler only deletes routes it manages by key from its manifest - it never flushes the main table that also holds DHCP and OS-installed routes.

Traffic Shaping

Hierarchical QoS - tc, HTB, HFSC, and cake

Firecradle's shaping engine is built entirely on Linux tc - never nftables - so it can never collide with the firewall table's flush-and-rebuild apply. Three building blocks compose every policy: Limiters (bandwidth pipes using HTB, TBF, or cake), Queues (hierarchical scheduler trees using HFSC, HTB, or strict-priority PRIQ), and Shaper Rules (classification and marking via flower/u32 filters). HFSC's service curves model three guarantees per queue - realtime, linkshare, and upperlimit - so latency-sensitive traffic gets a floor without starving everything else.

One-click presets seed a queue tree automatically: VoIP priority (DSCP EF), ACK prioritization, and gaming low-latency
DSCP marking (pedit munge dsfield) and priority marking (skbedit priority) classify by 5-tuple or existing markings
Ingress shaping is mirrored to a virtual IFB device for policing - true ingress queuing isn't something Linux tc does natively
Illustrative Queue Tree - WAN Interface
Root - WAN Interface
100% of link(HTB root qdisc)
Total available bandwidth for the interface
VoIP / Realtime (DSCP EF)
~10%(HFSC realtime curve)
Guaranteed floor - low latency, low jitter
Business / Interactive
~60%(HFSC linkshare)
Fair-share of remaining bandwidth, ACK-prioritized
Bulk / Best-Effort
~30%(fq_codel leaf)
Everything else - large transfers, updates, background sync
Percentages are configured per deployment, not fixed - a queue tree can nest as many child classes as the policy needs, as long as children never sum past their parent's bandwidth.
Shaping Building Blocks
Limiter
HTB / TBF / cake
A bandwidth pipe applied to an interface or address
Queue
HFSC / HTB / PRIQ
Hierarchical scheduler tree with per-class guarantees
Shaper Rule
flower / u32 + DSCP
Classifies and marks traffic into a queue class
VPN Architecture

Tunnel Establishment - WireGuard, IPsec, OpenVPN

Whichever tunnel technology a policy uses, Firecradle never hand-rolls the crypto or the interface plumbing - it drives the same production-grade tools those protocols were built around, and never touches the firewall table directly.

IKEv2 (strongSwan swanctl)ChaCha20Poly1305 (WireGuard)AES-256-GCM (OpenVPN)tls-crypt HardeningMOBIKE RoamingSite-to-Site & Road-Warrior
Tunnel Establishment Flow
Peer Configuration
WireGuard keypair (wg genkey / wg pubkey), an IPsec proposal (swanctl), or an OpenVPN certificate is generated or imported
Key Exchange / Auth
WireGuard's Noise handshake, strongSwan's IKEv2 SA negotiation, or OpenVPN's TLS handshake over tls-crypt
Tunnel Established
wg-quick up, swanctl --initiate, or the openvpn-server@ systemd unit brings the interface up
Encrypted Data Plane
Fixed ChaCha20Poly1305 (WireGuard) or negotiated AES-256/SHA-256 (IPsec, OpenVPN) protects every packet
Firewall Auto-Rule
The VPN module inserts a tagged permit rule for the listen port - it never edits table inet firecradle directly
Live Status
wg show all dump, swanctl --list-sas, or the OpenVPN management socket reports peers and traffic counters
Choose Your Tunnel - Pick One
WireGuard
Modern, minimal, fixed crypto
OR
IPsec (strongSwan)
Standards-based IKEv2
OR
OpenVPN
Broadest client compatibility
VPN Flexibility

Five Tunnel Types - One VPN Engine

The same firewall auto-rule integration backs every tunnel technology. Add the Hybrid Failover pattern when a single link isn't enough.

WIREGUARDDefault
Modern High-Performance Tunnels
  • wg-quick manages persistent config; wg syncconf hot-reloads peers without dropping the interface
  • Fixed ChaCha20Poly1305 AEAD cipher suite - no negotiation, no downgrade risk
  • Client export as a .conf file or a scannable QR code (qrencode)
  • Road-warrior and site-to-site peers coexist on the same interface
IPSECStandards-Based
IKEv2 via strongSwan swanctl
  • PSK, RSA, ECDSA, and EAP authentication methods
  • Default proposals: aes256-sha256-modp2048 (IKE) / aes256-sha256 (ESP)
  • Dead Peer Detection with a configurable restart action (30s default delay)
  • MOBIKE support keeps a roaming road-warrior session alive across network changes
OPENVPNBroad Compatibility
Certificate + tls-crypt Hardened
  • AES-256-GCM (AEAD - integrity built into the cipher) by default; SHA-256 secures the TLS control channel / tls-crypt
  • tls-crypt hardens the control channel against DoS and TLS fingerprinting
  • Per-client static IPs via client-config-dir (CCD)
  • Site-to-site mode reuses the identical server model
SITE-TO-SITEAlways-On
Persistent Inter-Office Tunnels
  • A fixed Endpoint peer over WireGuard or IPsec for a permanent connection
  • PersistentKeepalive traffic holds NAT bindings open on both sides
  • The firewall auto-inserts a tagged permit rule for the tunnel's listen port
  • Multiple peers provide redundant paths between sites
ROAD WARRIORRemote Access
Per-User Client Tunnels
  • Auto-generated client keypair with exported .conf and QR code (WireGuard)
  • EAP/XAuth authentication for IPsec remote-access peers
  • Inline .ovpn bundles - CA, cert, key, and tls-crypt in a single file (OpenVPN)
  • Certificates issued from the local PKI or via ACME / Let's Encrypt
HYBRID FAILOVEROptionalHybrid
Primary + Standby Tunnel
WIREGUARDIPSEC=Primary + Standby
Run WireGuard as the primary path and IPsec as a standby for the same site
Each technology keeps its own keys, proposals, and firewall auto-rule independently
A failed primary tunnel doesn't require touching the standby's configuration
Useful when a peer's network only allows one protocol through at a time
Security Architecture

Defense in Depth - At Every Layer

Encryption

IPsec Default Cipher Suite

IKE SA negotiated with aes256-sha256-modp2048, ESP data channel with aes256-sha256 - configurable per connection through strongSwan's swanctl, with ChaCha20 available as an alternate cipher.

Modern Crypto

WireGuard Fixed Cryptography

ChaCha20Poly1305 AEAD encryption with Curve25519 key exchange - the protocol ships one cipher suite by design, removing negotiation and downgrade attacks as a category entirely.

Control-Channel

OpenVPN tls-crypt Hardening

The control channel is wrapped with tls-crypt by default, hiding TLS handshake metadata from network observers and hardening the listening port against DoS scanning.

Threat Detection

Suricata Signature Engine

Inline (NFQUEUE) or detection-only (af-packet) inspection against ET Open, ET Pro, VRT, or custom rule sources. No black-box AI/ML - every match traces back to a signature ID.

Fail-Safe

Anti-Lockout Rule

A management-access allow rule is always prepended ahead of the default-drop policy, so a misconfigured ruleset push can't lock an administrator out of the appliance.

Change Safety

Validate-Then-Apply

Every config change is syntax-checked (nft -T, suricata -T) before it touches a live interface - a bad rule is rejected outright, never silently half-applied.

Default Tunnel Cipher Suites, by Protocol
WireGuard
ChaCha20Poly1305 - fixed, non-negotiable cipher suite
IPsec IKE SA
aes256-sha256-modp2048 (default proposal)
IPsec ESP (data)
aes256-sha256 (default proposal)
OpenVPN
AES-256-GCM (AEAD); SHA-256 on the TLS control channel

Every tunnel technology defaults to a 256-bit cipher. IPsec and OpenVPN proposals are configurable per policy; WireGuard's suite is fixed by protocol design - simplicity that also removes an entire class of downgrade attacks.

5 Monitored Jails × 3 Stages = 15 Watchpoints
SSH
Detect
SSH
Ban
SSH
Log
Admin UI
Detect
Admin UI
Ban
Admin UI
Log
WireGuard
Detect
WireGuard
Ban
WireGuard
Log
OpenVPN
Detect
OpenVPN
Ban
OpenVPN
Log
REST API
Detect
REST API
Ban
REST API
Log
Failed attempts parsed from auth logs in near real-time
Threshold exceeded (e.g. 5 failures in 10 minutes) triggers a ban
Source added to the firecradle_banned nftables set - dropped on the next packet
Brute-Force Protection

Stop Credential Attacks Before They Land

fail2ban watches authentication logs across every exposed service and bans offending sources into a dedicated nftables set - firecradle_banned - that the input chain drops against. It never creates a competing table, so it can't collide with the firewall module's atomic flush-and-rebuild apply.

Jails cover SSH, the web admin UI, and VPN auth endpoints out of the box
Bans land in an nftables set, not a separate ruleset - zero risk of a flush race
Configurable failure thresholds and ban durations per jail
Managed entirely through fail2ban-client - standard tooling, no proprietary agent
By the Numbers

Performance That Scales

100k+ PPS
Rule evaluation throughput target
Single unified nftables table
<10ms
Rule evaluation latency target
Sub-10ms path through the ruleset
10,000+
Concurrent tracked connections
Tested conntrack table load
20% / 40%
Gateway loss - warn / alert
Multi-WAN health monitor default
300 / 500ms
Gateway latency - warn / alert
Multi-WAN health monitor default
0
Unmanaged routes ever touched
Manifest-diff reconciliation, not a full flush
Architecture Layers

One Firewall - Every Network Layer

Layer 2 - Switching
802.1Q VLANs, QinQ, Link Bonding
  • 802.1Q VLAN tagging with optional QinQ (802.1ad) double-tagging for provider trunks
  • Link bonding modes: active-backup, balance-rr/xor, broadcast, with 802.3ad/LACP layered on top
  • Per-VLAN interface isolation, verified by automated end-to-end tests
  • miimon-based link monitoring drives bond failover detection
Layer 3 - Routing & NAT
Policy Routing, Multi-WAN, NAT
  • Policy-based routing via ip rule - match by source, destination, fwmark, or inbound interface
  • Multi-WAN gateway groups: failover, or ECMP weighted load-balancing
  • Manifest-diff reconciliation - never flushes the system's main routing table
  • Optional dynamic routing via FRR - BGP, OSPF, and RIP
Layer 4-7 - Filtering & Inspection
nftables, Conntrack, Suricata
  • Single unified nftables table with stateful conntrack matching (ct state)
  • Inline Suricata IPS via an NFQUEUE verdict handoff, or IDS-only detection over af-packet
  • ET Open, ET Pro, VRT, or custom signature rule sources
  • fail2ban brute-force jails layered onto the same input chain via an nftables set
Observability

Prometheus-Native Metrics Out of the Box

Firecradle exposes per-rule, per-connection, and per-queue telemetry out of the box - not just interface counters. Metrics are retained locally and exportable to any Prometheus-compatible stack.

Per-chain and per-rule packet/byte counters from the nftables ruleset
Conntrack table occupancy and per-flow state distribution
Suricata alerts by signature, category, and severity - tailed live from eve.json
Gateway health: loss percentage, RTT, and failover events per WAN
tc queue and class stats: sent, dropped, overlimits, and backlog per class
prometheus metrics output
firecradle_conntrack_active_total{table="main"}10482
firecradle_rule_eval_latency_ms{chain="forward"}6.2
firecradle_ids_alerts_total{severity="high"}134
firecradle_gateway_loss_ratio{gateway="wan1"}0.02
firecradle_wg_peer_last_handshake_seconds{peer="site-b"}42
firecradle_qdisc_dropped_packets{class="voip"}0

Why This Engineering Translates to Real Business Value

Predictable Line-Rate Performance

Targeting 100k+ PPS with sub-10ms rule evaluation, the firewall keeps up with real traffic without becoming the bottleneck on the network.

Fewer Blind Spots

A single unified nftables table means filter and NAT are always evaluated as one consistent ruleset, not two systems that can silently drift out of sync.

Verified Config Changes

Every apply is validated - nft -T, suricata -T - before it touches production, so a bad rule change never becomes a bad reload.

Resilient by Design

VRRP + conntrackd active/passive HA keeps sessions alive through a node failure; multi-WAN failover keeps traffic flowing through an ISP outage.

Threat Detection You Can Audit

Suricata plus ET Open/ET Pro/VRT rules - transparent and tunable, with no black-box model deciding what gets blocked.

Safe by Default

An anti-lockout rule and manifest-diff reconciliation mean a config push can't lock you out or wipe a route it doesn't own.

Ready to See the Engineering in Action?

Start a 30-day free trial - our team provisions your appliance and walks you through the packet pipeline firsthand.

No credit card required · Cancel anytime · 30-day free trial