I'm not happy with any router OS, so I'm trying something else

Technological concepts & project overview

• The speaker is upgrading a home-lab router using a Mono-Gateway 10Gb ARM router development kit (NXP Layerscape-based).
• Key hardware traits:
  • Hardware packet offloading / packet engine between CPU and NICs (routing + state tracking), enabling near 10Gb throughput without high CPU load.
  • Interfaces: two 10Gb, plus three 1Gb.
• Linux integration:
  • Using a combination of NXP tooling/API + Tamas’s work, the device can be controlled largely via standard Linux networking tools (e.g., ip commands).
  • With hardware offload, Linux features like firewall (nftables) can be applied and pushed down efficiently.

Operating system decision & automation goal

• The speaker dislikes OpenWrt and generally dislikes router platforms that depend on web UI workflows like pfSense/OpenSense.
• Goal: build a fully declarative router config that can be automated via Ansible and modeled in something like NetBox, rather than manually editing a web UI.
• OS options considered for the Mono-Gateway include:
  • OpenWrt
  • OpenSense
  • Debian/Armbian (officially supported)
• Main approach chosen:
  • Run Debian + systemd components and configure networking using systemd-networkd.
  • For DNS: use systemd-resolved.
  • For firewall/NAT: use nftables (written as scripts, later intended to be generated by Ansible).

Router functions implemented (proof of concept)

The “basic router” requirements the speaker targets:

WAN side

• DHCPv4 and DHCPv6 to receive addresses/prefixes.
• DHCPv6 prefix delegation (PD).
• Use RA (router advertisements) because DHCPv6 alone may not provide route information.

LAN side

• DHCPv4 server to hand out IPv4 addresses.
• Router advertisements (RA) for IPv6 prefixes and client configuration.
• IPv6 prefix options (multiple prefixes supported, including ULA/GUA patterns).

DNS

• Provide downstream DNS service via systemd-resolved (also mentions enabling mDNS).

VLAN support

• Uses systemd-networkd’s VLAN parent/child interface structure:
  • A parent interface config that creates VLAN children.
  • Separate netdev files for each VLAN interface (virtual device).
  • Separate network configs to address DHCP/RA on those VLANs.

“Declarative” design using systemd-networkd + nftables

systemd-networkd configuration style

• Uses systemd-networkd’s declarative config files (including the importance of file naming/sort order under /etc/systemd/network/... behavior).
• Matching and ordering:
  • Match sections bind config to interfaces (by name or MAC).
  • File numbering affects application order (lower numbers apply more specific configs first).
• Example concept: “backup” network using IPv6 ULA + mDNS
  • Configured on a dedicated Ethernet port so the admin system remains reachable:
    • mDNS at gateway.local
    • and SSH, even when the rest of the network is down.

Firewall/NAT via nftables script

• Uses nftables “script-like C file syntax” (as described) to keep the firewall declarative-ish and repeatable:
  • Script begins with a shebang and flushes/rebuilds rules each run.
  • Supports variables (e.g., WAN/LAN interface variables).
• Packet-flow model described by chains:
  • pre-routing (e.g., NAT/marking decisions)
  • input (packets destined to the router itself—DHCP/DNS/etc.)
  • forward (routed packets—main firewall logic)
  • output (router-generated traffic)
  • post-routing (e.g., SNAT/masquerade)
• NAT and port forwarding:
  • Port forwarding requires rules in multiple places:
    • destination rewrite in pre-routing
    • forward accept in forward
  • IPv4 example: forwards WAN:8080 → LAN VM:80 with masquerading.
  • IPv6 forward example: uses a prefix-suffix matching technique to avoid hardcoding full prefixes.

Performance / hardware offload results

• CPU efficiency demonstrated:
  • During gigabit tests, CPU usage on the gateway was around a few percent.
  • The observation is that offload kept CPU effectively idle for basic routing/NAT/firewall operations.
• Notes:
  • Mentions potential uncertainty for more complex offload cases (e.g., tunnels/encapsulations like PPPoE/IPsec-style), implying hardware offload may behave differently for advanced encapsulation.

ISP replacement and VLAN-based LAN setup

• Later goal: replace the ISP router, with plans to put the ISP router in bridge mode.
• Challenges:
  • ISP router DHCP/PD can be “huge pain,” so the setup depends on having the correct cable/mode working initially.
• WAN configuration:
  • WAN receives IPv4/IPv6 via DHCP, while RA behavior is explicitly used.
• LAN configuration:
  • Configures at least one VLAN (example: VLAN ID 20) with:
    • IPv4 subnet addressing and DHCPv4 server pool
    • RA lifetimes (example: 1800s)
    • IPv6 prefix handling via delegated prefix from upstream.

Tunneling & future automation plan

• Long-term automation:
  • Wants to automate everything with Ansible templates filled by NetBox data.
• Tunnel topic:
  • Plans to build tunnels from the gateway to other locations (e.g., Poland/Warsaw and US sites mentioned) to use advertised IP space.
  • Notes that tunnel punch-through / CPE firewall issues made testing harder.
  • Ultimately avoids complex tuning (e.g., specific routing keepalive/punchthrough parameters) for now.
  • Uses systemd-networkd templates to generate peer-to-peer tunnel configs; automation is planned similarly via Ansible once verified.

Guides/tutorial takeaways (what to replicate)

• Use systemd-networkd + systemd-resolved + nftables to build a router without relying on a web UI OS.
• Implement router basics:
  • DHCPv4 server (LAN)
  • DHCPv4/v6 client + DHCPv6 PD (WAN)
  • RA for IPv6 on LAN
  • DNS via systemd-resolved
  • VLANs via parent/child networkd units
• For firewall:
  • Use an nftables script that rebuilds rules cleanly each run.
  • Understand nftables chains for correct NAT/port-forwarding behavior.
• For automation:
  • Keep configs declarative so Ansible manages state without hand-crafted imperative command sequences.
  • Start by migrating downstream LAN/VLAN sections first, then extend to more advanced routing/policy edge cases.

Main speakers / sources

• Speaker: “Tamas” (referred to and credited indirectly), plus the narrator/author of the video (the person building the router; pre-order #59).
• Primary source referenced: Tamas’ Mono-Gateway documentation/content on YouTube (and his development work on the router).