menu
Network Sandbox Engine v2 - testing nftables rules in a real kernel environment, risk-free

Network Sandbox Engine v2 - testing nftables rules in a real kernel environment, risk-free

●1 ●2 ●16
calendar_today • schedule1 min read

I built NSE (Network Sandbox Engine) because testing nftables rules on a live system is dangerous. One bad rule can leave orphan tables behind.

NSE solves this by creating an ephemeral Linux network namespace, loading your ruleset, injecting synthetic packets, and capturing kernel verdicts via nft monitor trace. The host firewall never gets touched.

What's new in v2.0.0:

  • In-process architecture - removed the rootd socket daemon. Everything runs in a single process.
  • Pydantic core - all data models are strongly typed. The entire codebase passes mypy --strict.
  • Deterministic trace harvesting - no more hardcoded sleep delays. NSE waits for kernel traces to be ready and returns real verdicts (ACCEPT/DROP/REJECT).
  • Automated cleanup - startup sweeps orphaned namespaces. Teardown uses exponential backoff retries.
  • Gateway topologies - support for router + server namespaces to test NAT and forwarding rules.
  • MkDocs documentation with mkdocstrings for API reference.
  • import-linter enforces architectural boundaries between core and GUI.

How to use it:

  • As a Python library - import nse and write packet-level tests.
  • As a CLI for CI/CD - write YAML test definitions and run nse-runner.
  • With the web UI - FastAPI backend + Svelte frontend for real-time packet tracing and conntrack visualization.

Requirements: Linux (kernel 5.4+), Python 3.10+, nftables, iproute2, root privileges.

Links:

I'm looking for feedback. What would make this useful for your workflow? What's missing?

4 Comments

•

Really useful approach. Testing nftables in an isolated namespace without risking the host sounds like a big win. How has the CI/CD workflow been so far?

2 votes
•

@Mehadi Hasan Thanks for your comment. CI/CD has been the main driver for the v2 rewrite - I'm using it in GitHub Actions with the CLI runner, and the deterministic trace harvesting made the biggest difference for reliability in CI. No flaky tests so far.

NSE actually started as a validation tool for another project of mine: TTP (a transparent Tor proxy). I needed a deterministic way to prove that the firewall rules weren't leaking any packets. NSE doesn't cover 100% of the tests I need yet, but I figured it could be useful to others as well.

Are you running any nftables tests in CI? Curious about your setup.

1
•

This is a great approach to firewall testing. Running nftables rules in an isolated, real kernel environment makes testing much safer while still giving realistic verdicts. The deterministic tracing and automated cleanup in v2 are especially useful for CI/CD workflows. Great project

2 votes
•

@[kennytm] Thanks for the feedback. The namespace isolation was actually the first thing I built - everything else grew from there.

Are you planning on using nftables in production? Would love to hear what rulesets you're testing.

0
🔥 Join developers growing publicly
Share your knowledge, build in public, and grow your developer presence with a global community.
Join CoderLegion

More Posts

MCP Is the USB-C of AI. So Why Are You Plugging Everything In?

Ken W. Algerverified - Jun 10

Comparison: Universal Import vs. Plaid/Yodlee

Pocket Portfolio - Mar 12

Attention-Free Score: How Domain Reports Show Which Pages Need Work

ApogeeWatcherverified - Sep 1

The Interface of Uncertainty: Designing Human-in-the-Loop

Pocket Portfolio - Mar 10

My Nginx Died at 2 AM and Nobody Noticed for 6 Hours. Now I Have a Watchdog Script

BashSnippets - May 21
chevron_left
onyks
206 Points • 19 Badges
onyks-os.github.io
1Posts
5Comments
3Connections
https://github.com/onyks-os

Related Jobs

View all jobs →

Commenters (This Week)

3 comments
3 comments

Contribute meaningful comments to climb the leaderboard and earn badges!