DIY Debian Router - Epilogue

The end

Throughout this series, we transformed a general-purpose Debian system into a production router - constructing the network infrastructure using a fairly foundational approach. Each component we configured (systemd-networkd, nftables, Unbound, Kea, WireGuard) represents a deliberate architectural choice prioritizing transparency, control, and security over convenience.

Typical open-source and consumer routers abstract away complexity, which serves most very well. However, by doing it yourself, you learned a shit ton and could argue that you now have more control over your home network.

Building this was admittedly more work. But this work yields something valuable: knowledge of how these systems actually function, and the ability to reason about their behavior under both normal and adversarial conditions. In an era where network infrastructure is increasingly critical yet increasingly opaque, this understanding matters.

To recap, in this series we covered:

• Part 1: Foundations and Network Architecture: Architectural overview and design decisions
• Part 2: Core Network Configuration with systemd-networkd: Interface setup, bridging, and network configuration using systemd-networkd
• Part 3: DNS Infrastructure with Unbound: Recursive resolver configuration, DNSSEC, and blocklist integration
• Part 4: DHCP Services (IPv4 with Kea): Address pool management, lease tracking, and DHCP options
• Part 5: IPv6 Deployment with SLAAC: Router Advertisements, ULA/GUA addressing, and prefix delegation
• Part 6: Firewall Architecture with nftables: Stateful filtering, NAT, anti-spoofing, and attack mitigation
• Part 7: System Hardening and Kernel Tuning: sysctl security policies, performance optimization, and DoS mitigation
• Part 8: WireGuard VPN for Secure Remote Access: Encrypted VPN tunnel for secure remote LAN access
• Part 9: Port Forwarding with nftables: Exposing services to the Internet with nftables DNAT
• Part 10: Dynamic DNS with ddclient: Tracking changing public IP addresses for reliable remote access

Next steps

The router we built is functional and secure, but there is so much more to explore and improve. Some directions worth exploring:

VLAN segmentation for guest/IoT networks: VLANs can isolate untrusted devices (IoT, guest networks) from your primary network. The question is not whether to segment, but how granular to make the isolation. Each VLAN boundary represents a trust boundary that must be explicitly bridged through firewall policy.

Traffic shaping (QoS) for bandwidth management: Bandwidth is finite. QoS mechanisms (traffic shaping, prioritization) determine which flows receive preferential treatment during congestion. This raises interesting policy questions: should interactive traffic always preempt bulk transfers? How do you prevent one device from monopolizing bandwidth? These are fundamentally resource allocation problems.

Intrusion detection (IDS) (e.g., Suricata or Snort): We configured security controls, but lack visibility into whether they are effective. Intrusion detection systems can identify attack patterns in network traffic through signature matching and anomaly detection. The gap between "configured security" and "verified security" is often larger than we assume.

Centralized logging with rsyslog or journald forwarding: Correlating events across multiple components (firewall drops, DNS queries, DHCP leases, authentication attempts) requires aggregating logs to a central location. Flow monitoring tools (NetFlow, sFlow) can complement system logs by revealing traffic patterns and anomalies at the network layer.

High availability with VRRP/keepalived: A single router represents a single point of failure. VRRP or keepalived can enable failover between redundant routers, but introduces complexity around state synchronization (connection tracking, DHCP leases). The trade-off between simplicity and resilience depends on your tolerance for downtime.

DNS over TLS/HTTPS (DoT/DoH): Unbound provides recursive resolution, but upstream queries remain plaintext. Forwarding to DoT/DoH resolvers (Quad9, Cloudflare) encrypts DNS traffic from ISP surveillance, though at the cost of trusting the upstream resolver. Alternatively, running your own authoritative zones eliminates external dependencies entirely for internal domains.

Network tap and packet capture infrastructure: Deep traffic analysis requires packet capture beyond what IDS provides. A dedicated monitoring port (switch SPAN/mirror port) feeding tcpdump, Wireshark, or Zeek enables forensic analysis, protocol debugging, and compliance auditing. The question is where to store captures - full packet capture at line rate consumes substantial storage.

Automated security updates and patch management: Security is temporal. The system we built requires ongoing maintenance - kernel updates, package upgrades, configuration drift detection. Considering this is important, and sooner is better than later.

Egress filtering and data exfiltration controls: We focused on ingress filtering, but compromised internal devices can exfiltrate data. Restricting outbound traffic by protocol, destination, or volume requires understanding legitimate baseline behavior. Too restrictive breaks functionality; too permissive defeats the purpose. This is the fundamental problem of anomaly detection.

All that being said, the foundation is now built. What you construct on top of it depends on your interests, threat model, requirements, and your willingness to maintain increasing complexity.

Enjoy.