DIY Debian Router - Part 1: Foundations and network architecture

Oct 7, 2025

Overview

This mini-series documents the construction of a DIY router based on Debian Linux. The router will provide core networking services: packet forwarding, firewall, DHCP, DNS, and dual-stack IPv4/IPv6 support.

Design principles and threat model

Security posture

The router operates as a trust boundary between untrusted WAN (Internet) and trusted LAN (internal network). The security model enforces:

  1. Default-deny on WAN ingress: All unsolicited inbound traffic from the Internet is dropped unless explicitly required (e.g., DHCP client traffic)
  2. Stateful connection tracking: Only established/related connections traverse the firewall
  3. Anti-spoofing enforcement: Bogon filtering and reverse path filtering prevent source address spoofing
  4. Attack surface minimization: WAN-facing services are limited to DHCP client functionality; no SSH, HTTP, or other management interfaces are exposed

✏️ Later posts will go over port forwarding for exposing specific services on the public Internet and setting up WireGuard for secure access to LAN services when away from home

The threat model assumes:

  • Attackers control the WAN interface (arbitrary packets can arrive from the Internet)
  • LAN clients are trusted but may be compromised (defense-in-depth still applies)
  • Physical access to the router is restricted to home/business owner
  • Firmware/software supply chain integrity is maintained through package signature verification

Software selection rationale

Debian Linux: Chosen for its stability, long-term support (LTS releases), and conservative package update policy. Debian's security team provides timely patches without the instability of rolling-release distributions.

systemd-networkd: A network management daemon included with systemd. Provides native support for bridge interface management, DHCPv6 Prefix Delegation and Router Advertisement generation, eliminating the need for separate wide-dhcpv6-client and radvd daemons. systemd-networkd offers a nice, declarative approach to network configuration with integrated IPv6 support.

nftables: The new Linux packet filtering framework, replaces legacy iptables. nftables provides cleaner syntax, better performance through connection tracking optimization, and more efficient rule evaluation.

Kea DHCP: ISC's next-generation DHCP server, designed as a replacement for the now-EOL ISC DHCP. Provides DHCPv4 (and DHCPv6, but we'll ignore that) capabilities with JSON-based configuration, lease persistence, and control socket integration for dynamic management.

Unbound: A validating, recursive DNS resolver focused on security and privacy. Unbound supports DNSSEC validation, DNS blocklist integration, and minimal-logging operation suitable for privacy-conscious deployments. We'll generate a custom blocklist to block unwanted spam and other bad domains for Unbound.

Network topology and hardware considerations

Hardware requirements

You can follow this guide with any hardware running any architecture. Figuring out whether or not your specs are enough is up to you.

In my setup, I'll be using a x86-64 based QDNV01 Qotom device. For reference, this device has the following specs:

  • CPU: Intel Atom C3558R (4 cores @ 2.40 GHz)
  • RAM: 8G RAM
  • Storage: 120 GB SSD
  • NICs:
    • 5x Ethernet I226-V (2.5Gbe each)
    • 4x SFP+ X553 (10 GbE each) - not used in this guide

Interface layout

Using all five ports, I'll be setting things up as follows:

  • WAN interface (enp8s0): Single uplink to ISP modem/ONT, receives public IPv4 via DHCP and IPv6 prefix via SLAAC/DHCPv6-PD
  • LAN interfaces (enp4s0, enp5s0, enp6s0, enp7s0): Four Ethernet ports bridged into a single Layer 2 broadcast domain

No VLANs are implemented, though support for VLAN tagging is easy to add if future segmentation is required (e.g., guest network, IoT isolation).

Bridge vs. routing

The LAN interfaces are configured as a Linux bridge (br0) rather than individual routed subnets. This provides:

  1. Transparent Layer 2 connectivity: Clients on any LAN port can communicate directly without router mediation
  2. Simplified DHCP/DNS management: Single subnet (192.168.0.0/24) simplifies address assignment and DNS record management
  3. Broadcast domain unification: ARP, mDNS, and other discovery protocols function across all LAN ports

The tradeoff is loss of inter-segment isolation; all LAN clients are in the same security domain. For most residential/SOHO deployments, this is acceptable. Environments requiring strict segmentation (e.g., separate guest/IoT networks) should implement VLAN-tagged subinterfaces instead of a flat bridge.

IPv4 and IPv6 dual-stack architecture

IPv4 design

The internal IPv4 network uses RFC1918 private addressing:

  • LAN subnet: 192.168.0.0/24
  • Gateway/router: 192.168.0.1
  • DHCP pool: 192.168.0.150 - 192.168.0.250

IPv4 network address translation (NAT) is implemented via nftables masquerading, translating internal addresses to the router's dynamically-assigned public IPv4 address.

IPv6 design

The IPv6 architecture implements dual addressing:

  1. Global Unicast Addresses (GUA): ISP-delegated prefix (typically /56 or /64), obtained via DHCPv6 Prefix Delegation (PD) or SLAAC. Clients receive public IPv6 addresses routable on the Internet.

  2. Unique Local Addresses (ULA): For example: fd09:dead:beef::/48 (should be randomly generated per RFC4193). ULA provides stable internal addressing independent of ISP prefix changes, analogous to RFC1918 in IPv4 but without NAT.

IPv6 does not use NAT. All LAN clients receive globally routable GUA addresses and can initiate outbound connections directly. The firewall enforces stateful filtering to block unsolicited inbound traffic, maintaining security without the complexity and breakage introduced by NAT.

SLAAC vs. DHCPv6

I'll be using Stateless Address Autoconfiguration (SLAAC) for IPv6 client addressing rather than DHCPv6. Reason:

  • Simplicity: SLAAC requires only Router Advertisements (RA), no separate DHCP server
  • Compatibility: SLAAC is universally supported; DHCPv6 client support is inconsistent (apparently, Android lacks DHCPv6 support as of writing)
  • Statefulness: SLAAC is truly stateless; the router does not track lease assignments

For environments requiring centralized IPv6 address assignment tracking, DHCPv6 remains an option, and can be provided by Kea.

Service architecture overview

In summary, the router will provide four core network services:

1. Packet forwarding and NAT

  • IPv4: Masquerading (SNAT) for outbound traffic, translating internal to public address
  • IPv6: Stateless forwarding with firewall enforcement

2. Firewall (nftables)

  • Stateful packet filtering with connection tracking
  • Default-deny ingress policy on WAN
  • Anti-spoofing via reverse path filtering and bogon lists
  • ICMP/ICMPv6 rate limiting to prevent flooding

3. DHCP (Kea for DHCPv4, SLAAC for IPv6)

  • Dynamic address assignment with lease management
  • Static reservations by MAC address
  • DHCP option distribution (gateway, DNS, domain)

4. DNS (Unbound)

  • Recursive resolver with DNSSEC validation
  • DNS-based ad/tracker blocking via curated blocklists
  • Local domain resolution for internal hostnames
  • Root hints for authoritative DNS traversal

Additionally, we'll explore how to setup WireGuard for secure access to your entire network when not at home (Part 8), how to do port forwarding to expose internal services to the public Internet (Part 9), and how to configure Dynamic DNS to track changing public IP addresses (Part 10).

Series roadmap

The remaining parts of this series cover:

Each subsequent part builds incrementally on the foundation established here, with complete configuration files and detailed implementation notes.

© 2025 Absurdum
RSS
https://yusefkarim.absurdum.ca/posts/feed.xml