Computer Networks

Jump to the Router Examples

Almost everything we do on a computer today depends on a network, yet most of us only notice it when it stops working. Below you will find the basic ideas, a bit of history, an overview of the protocols that came and went, and then a practical part: what to look at when you configure a home router and how to build one yourself from open-source software.

What Is a Network?

In the broadest sense, a network is a set of things and the connections between them. Roads connect cities, friends connect through conversations, neurons connect through synapses. A computer network is the same idea applied to devices that exchange data. It always needs three ingredients:

Three ingredients of every computer network:

A useful comparison is the postal system. You write a letter (data), put it in an envelope with an address (header), and the post office (routers) forwards it from sorting centre to sorting centre without knowing what is inside. If the letter is too large, you split it into several envelopes and the recipient puts them back together. Computer networks work in a surprisingly similar way – this is called packet switching. The older approach, used by classic telephony, reserves a whole line for the duration of the call; this is circuit switching.

Networks by size:

• PAN – personal area: a phone, headphones and a watch talking over Bluetooth.
• LAN – local area: a home, an office, a school.
• MAN – a city or campus.
• WAN – a wide area, e.g. a company connecting branches in different countries.
• The Internet – literally a "network of networks": thousands of independently run networks that agreed to use the same protocols.

Networks also differ in how the nodes are arranged – the topology (bus, star, ring, tree, mesh) – and in how they share roles. In the client–server model some devices only provide services and others only request them, while in peer-to-peer networks every node can be both. Your home network is a star (everything connects to a central device), and the Internet is a partial mesh.

Layers and addresses. Because a network is too complicated to think about all at once, we split it into layers, where each layer only talks to the one above and below it. The theoretical OSI model has seven layers, the practical TCP/IP model that the Internet really uses has four. Each layer also has its own kind of address:

The TCP/IP layers and the addresses they use:

The devices you meet most often are easy to mix up, so here is the short version. A switch connects devices inside one network and forwards frames by MAC address. A router connects different networks (for example your home network and the Internet) and forwards packets by IP address. An access point is a bridge between the cable and the radio. A modem converts the provider's medium (cable, DSL, fibre) into Ethernet. What you buy as a "Wi-Fi router" is usually all of these except the modem, packed into one box.

Some resources:

• Computer network (Wikipedia)
• RFC 1122 – Requirements for Internet Hosts
• Cloudflare Learning Center – network layers
• Wireshark – the best way to understand networks is to look at real packets
• GNS3 and Mininet – open-source tools for building virtual networks

A Bit of History of Connecting Devices

The idea of sending messages over a distance with electricity is older than computers. The electrical telegraph appeared in the 1830s and 1840s and the telephone in 1876. The telephone network later became the first "wide area network" for computers: in the 1950s and 1960s, systems such as the American air-defence network SAGE and the airline reservation system Sabre connected terminals to central computers over leased telephone lines.

The 1960s brought the key idea. J. C. R. Licklider described a vision of an "intergalactic" network of computers around 1962. Independently of each other, Paul Baran in the USA and Donald Davies in the UK came up with splitting messages into small blocks – Davies named them "packets" – that find their own way through the network. Baran was thinking about a network that survives the loss of some of its nodes. On 29 October 1969, the first message was sent over the ARPANET from a computer at UCLA to one at the Stanford Research Institute; the system reportedly crashed after the first two letters of the word "LOGIN". By the end of the year the network had four nodes.

In the 1970s the network started to grow and diversify. In 1971 Ray Tomlinson sent the first network email and chose the @ sign for addresses. In France, Louis Pouzin built CYCLADES, which demonstrated that the network itself can be simple and the reliability can be left to the end devices – an idea that strongly influenced the Internet. In 1973 Robert Metcalfe and colleagues at Xerox PARC sketched Ethernet, and in 1974 Vint Cerf and Bob Kahn published the design of a protocol for connecting different networks, which later split into TCP and IP. Meanwhile, ordinary dial-up systems such as UUCP and Usenet connected universities and enthusiasts without any access to the ARPANET.

On 1 January 1983 the ARPANET switched from its old protocol to TCP/IP in what is usually remembered as a "flag day". That is why many consider this date the birth of the Internet. The same year, the Domain Name System was designed so that people no longer had to maintain a single shared list of host names. In the second half of the 1980s NSFNET connected the universities, and the ARPANET was shut down in 1990. At CERN, Tim Berners-Lee proposed the World Wide Web in 1989, and in 1993 CERN released the technology to the public. The web is not the same thing as the Internet – it is only one of the services running on it, albeit the most visible one.

The 1990s were the decade of commercialisation: the NSFNET backbone was retired in 1995 and the traffic moved to commercial providers. At the same time, the cable was disappearing. The first 802.11 standard appeared in 1997, and the Wi-Fi name was introduced in 1999. In the same period the world realised that the 32-bit addresses of IPv4 will not be enough, and the design of IPv6 was published in 1998. The central pool of free IPv4 addresses was exhausted in 2011, which is why we still stretch the old addresses with tricks such as NAT. From the 2000s on, mobile networks (3G, 4G, 5G) and the "Internet of Things" put billions of small devices on the network.

A short timeline:

Some resources for history:

• History of the Internet (Wikipedia)
• Brief History of the Internet (Internet Society)
• The birth of the Web (CERN)
• ARPANET (Wikipedia)
• Computer History Museum

Protocols – Those That Were and Those That Are

Protocols are published as open documents. The Internet ones are called RFCs (Request for Comments) and are developed by the IETF, while the standards for cables and Wi-Fi come from the IEEE 802 committee. The openness is probably the most important reason why a network of so many different manufacturers works at all. Many protocols have still disappeared, usually because something simpler, cheaper or more secure replaced them.

Some protocols that have mostly disappeared:

What is in use today? The table below shows the most important ones, sorted by layer. It is intentionally incomplete – there are thousands of protocols – but if you know these, you can follow most of what happens on a home or office network.

Protocols in use today (my own selection, not a complete list):

A few trends are worth noticing. First, almost everything now rides on IP; telephony, television and industrial controls all moved from their own networks to the same one, which is practical but also means that one problem can now affect many things. Second, encryption became the default: the web moved to HTTPS, DNS and even the transport layer (QUIC) are encrypted, and the Wi-Fi security standard evolved from WEP through WPA2 to WPA3. Third, IPv6 is slowly winning. Google's measurements show that a large part of users, somewhere around half, already reach it over IPv6; the exact number varies by country and by day, so check the live chart. In the meantime, NAT and carrier-grade NAT keep IPv4 alive, and both make direct connections to your home from outside harder.

Some resources for protocols:

• RFC Editor
• IETF
• IANA – Protocol registries (ports, numbers)
• IEEE 802 LAN/MAN Standards Committee
• Wi-Fi Alliance
• Google IPv6 Statistics
• Test your IPv6 connectivity

Example: A Home Network with a Router

A typical home network looks like this: the provider's modem (or optical terminal) brings the Internet to the router; the router connects to a switch and an access point, and those connect everything else. In most homes all of this is in a single box supplied by the provider, but it is still useful to understand which job is done by which part.

Internet
   |
[ Modem / ONT ]            (provider's medium -> Ethernet)
   |   WAN: public IP (or a "private" one if the provider uses CGNAT)
[ ROUTER ]                 NAT, firewall, DHCP, DNS forwarding
   |   LAN: 192.168.1.1/24
   +--[ Switch ]--- PC, NAS, printer (cable)
   |
   +--[ Access point ]--- phones, laptops, TV, smart devices (Wi-Fi)

Example addressing plan for a small home network:

Working with network equipment can lock you out of your own network, and wrong settings can expose your devices to the Internet. Write down the original settings, make a backup of the configuration and check your provider's terms before you change anything. Should you decide to act upon any information on this website, you do so at your own risk!

What to watch out for in the settings:

• Access to the router itself. Change the default administrator password right away (the default is often printed on the label and sometimes the same for a whole batch of devices). Use a long unique password, and if the router supports it, a separate account name. Limit the admin interface to the LAN – turn off "remote management" / "web access from WAN" unless you really need it. If you do, use a VPN instead of exposing the interface.
• Firmware updates. The router is the only device that is directly reachable from the Internet, so unpatched firmware is the most common way into a home network. Enable automatic updates if they exist, or set a reminder to check. If the manufacturer no longer publishes updates, that is a good reason to look at open-source firmware.
• Wi-Fi encryption. Use WPA3 if all your devices support it, or WPA2/WPA3 mixed mode, or WPA2-AES at the very least. Never use WEP, WPA or TKIP. A passphrase of several random words is better than a short complicated password. The network name (SSID) is not secret, but avoid names that reveal who you are or the router model.
• Turn off WPS. The PIN method has known weaknesses and the convenience is not worth the risk.
• Turn off UPnP if you can. It lets any program on your network open ports towards the Internet without asking you. If some game or application does not work without it, open only the port you need with a manual port forward.
• Be careful with port forwarding. Every forwarded port is a door to the Internet. Forward only to devices that you keep updated, use non-default services with strong authentication and, where possible, replace forwarding with a VPN.
• Firewall. The default should be "block all incoming connections that were not requested from inside". Check that this also applies to IPv6. With IPv6 every device can have a globally reachable address and NAT is no longer there to hide it, so the firewall is the only protection.
• Separate guests and smart devices. A guest network (with client isolation) for visitors and another for cameras, TVs and other "smart" devices means that a compromised light bulb cannot reach your computer or the NAS. More flexible routers can do the same with VLANs. This is closely related to the thoughts in the Security Considerations note.
• DHCP and DNS. Make sure the DHCP pool does not overlap with the fixed addresses. Decide which DNS server you use: your provider's, a public one, or your own (e.g. Pi-hole or Unbound on the router). Whoever runs your DNS sees which sites you visit, so this is also a privacy choice. If your router supports encrypted DNS (DoT / DoH), enable it.
• Wi-Fi channels and bands. On 2.4 GHz only channels 1, 6 and 11 do not overlap (in Europe also 13 in a similar pattern), and a 20 MHz width is usually the best choice there. The 5 GHz and 6 GHz bands are faster and less crowded but have a shorter range through walls. Placement of the access point – central, high and away from metal and microwave ovens – often matters more than any setting.
• Double NAT and the provider's box. If you add your own router behind the provider's router, you create a "double NAT", which breaks port forwarding and some games and calls. The solution is to put the provider's device into bridge mode (if allowed) or to place your router in its "DMZ"/exposed-host mode. Also check if your provider uses CGNAT – in that case you do not have a public address at all and incoming connections from the Internet are not possible without a relay or VPN service.
• Disable what you do not use. Telnet, SSH from the WAN, SMB or FTP file sharing on the router, cloud accounts and "remote assistance" features – each one is an additional attack surface.
• Logs, time and backups. Set the correct time (NTP) so that the logs make sense, glance at the list of connected devices once in a while, and export the configuration after every important change.

A few useful commands for checking what you have (they work in most terminals, with small differences between systems): ping 192.168.1.1 (is the router reachable), traceroute example.com or tracert example.com on Windows (where the path breaks), ip addr or ipconfig (my addresses), and nslookup example.com (does DNS work). To see what is exposed from the outside, run a scan of your own public address with a service such as ShieldsUP, and scan only your own network with Nmap.

Some resources:

• CISA – cybersecurity guidance
• NCSC (UK) – device and home network guidance
• ShieldsUP – port check
• DNS leak test
• Wireshark and tcpdump – see what really passes through your network
• iPerf – measure the speed inside your own network

Segmenting the Network and Remote Access: VLANs and VPN

Once the basics work, two features turn a "working" network into a well-designed one: separating devices that do not need to talk to each other, and reaching your network safely from outside. The first is done with VLANs, the second with a VPN. Both are used in the DIY router example below.

VLAN – one cable, several separate networks. A virtual LAN splits one physical network into several logical ones. With IEEE 802.1Q, an Ethernet frame gets a small tag with a VLAN ID (1–4094), and switches and routers keep frames with different IDs apart, as if they were on different cables. Two kinds of switch ports matter: an access port carries a single untagged VLAN and is meant for ordinary devices, while a trunk port carries several tagged VLANs and connects the router, switches and access points. Every VLAN is normally its own subnet, so traffic between VLANs has to go through the router – and that is exactly where your firewall rules apply.

Example segmentation (the same numbers are used in the Linux router example below):

What to watch out for with VLANs:

• You need the right hardware. An unmanaged switch ignores or mishandles tags. Look for a "smart" or managed switch with 802.1Q support (some are very cheap), and an access point that can map several SSIDs to different VLANs (OpenWrt can do this on many models).
• Be strict about trunks. Allow only the VLANs that are really needed on each trunk, and never put an untrusted network on the native (untagged) VLAN of a trunk. Unused ports should be switched off. Misconfigured trunks are the classic way around VLAN separation.
• The separation is only as good as the firewall rules. VLANs by themselves only create separate networks; if the router allows everything between them, nothing has been gained. Default to "deny" between VLANs and add exceptions one by one.
• Management on the trusted network. The admin pages of the switch and access point should be reachable only from the trusted VLAN.
• Expect some discovery problems. Casting, AirPrint and smart-home apps rely on multicast (mDNS) that does not cross VLANs. You can allow specific connections, or use a reflector such as Avahi – but only if you understand what you are opening.
• Segmentation does not replace updates. It limits the damage when an IoT device is compromised; it does not make the device safe.

VPN – reaching home without opening doors. A VPN creates an encrypted tunnel between two devices or networks. For a home network the most useful case is remote access: instead of forwarding ports to the NAS, the camera and the admin page, you forward one port to the VPN and reach everything else through the tunnel. WireGuard is the modern, simple choice: it is part of the Linux kernel since version 5.6, has a small code base (described in its paper), and does not answer packets from anyone who does not hold a valid key, so a port scan sees nothing. OpenVPN and IPsec are older alternatives that are still very common, especially in companies.

What to know before you set it up:

• Every device has its own key pair. The router knows the public keys of the allowed devices and which addresses each of them may use (AllowedIPs). Never share a private key; to remove a device, delete its peer entry.
• Your router must be reachable. You need a public IP address (IPv4 or IPv6) and one forwarded or allowed UDP port. If your provider uses CGNAT, incoming connections do not work – use IPv6, a small relay server, or a mesh solution built on WireGuard such as Headscale or NetBird. If your address changes, use a dynamic DNS name (many routers have a client built in).
• Split or full tunnel. In a split tunnel only the traffic for your home network goes through the VPN; in a full tunnel all traffic does (useful on public Wi-Fi). Which one it is depends on the client's AllowedIPs setting.
• A VPN is not anonymity. It moves trust from the local network to the other end of the tunnel. A VPN to your own home protects you on public Wi-Fi; a commercial VPN just means that someone else sees your traffic.
• Treat VPN clients as users of your network. Give the VPN its own firewall zone and decide what it may reach, instead of assuming it is automatically safe.

# Generate a key pair on each device (the private key must never leave it)
umask 077
wg genkey | tee router.key | wg pubkey > router.pub

# /etc/wireguard/wg0.conf  -- on the router
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = ROUTER_PRIVATE_KEY

[Peer]
# my phone
PublicKey = PHONE_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

# On the phone / laptop
[Interface]
Address = 10.8.0.2/24
PrivateKey = PHONE_PRIVATE_KEY
DNS = 192.168.50.1

[Peer]
PublicKey = ROUTER_PUBLIC_KEY
Endpoint = home.example.org:51820
# split tunnel: only home traffic goes through the VPN
AllowedIPs = 192.168.50.0/24, 10.8.0.0/24
# full tunnel instead: AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

On a Linux router you start the tunnel with systemctl enable --now wg-quick@wg0; OpenWrt and OPNsense have WireGuard in their web interfaces (OPNsense in recent versions, OpenWrt as a package). The firewall also has to allow the UDP port on the WAN side, which is included in the firewall example below. The most common reasons for a tunnel that "does not connect" are a wrong public key, a blocked UDP port, CGNAT, or an endpoint name that no longer points to your current address.

Some resources:

• IEEE 802.1Q (Wikipedia)
• OpenWrt – VLAN and switch configuration
• WireGuard Quick Start
• WireGuard: Next Generation Kernel Network Tunnel (paper)
• Headscale and NetBird – open-source WireGuard meshes

Example: Building Your Own Router with Open-Source Software

Why would you do this? Maybe because the manufacturer of your router has stopped publishing updates, because you want to know exactly what the device does, or because you simply want to learn. A router is not magic – it is a computer with at least two network interfaces that forwards packets between them and, by the way, also acts as a firewall, a DHCP server and a DNS forwarder. There are two basic paths: replacing the firmware of a router you already own, or turning a general-purpose computer into a router (for example the old computer from the Reviving an Old Computer note).

Open-source options (my own judgement, not test results):

A few practical points before you start. For a PC-based router you need two network ports (one for the WAN and one for the LAN); a USB Ethernet adapter works as a cheap second port, but it is less reliable. Prefer well-supported network chips (Intel is the safe choice). A processor with hardware AES support helps if you plan to run a VPN. Do not use the computer's built-in Wi-Fi as your main access point – it is much better to use a dedicated access point (for example a cheap router flashed with OpenWrt and set to "access point" mode). Remember also that if the router is a computer, it consumes more electricity than a small consumer router, so it makes sense only if you also use its flexibility.

Replacing the system on a PC – the procedure:

1. Prepare the hardware. Check that the computer has two network ports and that the disk and memory are healthy (see smartmontools and Memtest86+). A modest machine is enough – a few GB of storage and 2 GB of memory handle a home connection comfortably.
2. Keep a plan B. Do not throw away the old router. Leave it configured and ready, so that if something breaks, you can swap the cable and the household will still have Internet.
3. Collect the provider's data – connection type (DHCP, PPPoE, static), possible VLAN tag, username and password. Some providers also require a specific MAC address or have separate settings for television.
4. Download the image from the official site and verify the checksum, for example sha256sum filename.img, then compare the result to the value published by the project.
5. Write the image to the USB stick with Ventoy, balenaEtcher or Rufus, and boot the computer from it.
6. Install and assign the interfaces. The installer will ask which port is the WAN (towards the modem) and which is the LAN (towards your devices). A simple trick is to unplug and plug a cable and see which port reports the link.
7. Set the LAN. Choose an address for the router (e.g. 192.168.1.1/24 or something less common if you ever plan to connect to another network with the same range), enable the DHCP server and set the DNS.
8. Set the WAN. Usually DHCP, or PPPoE with the credentials from your provider. Make sure the firewall blocks all unsolicited incoming traffic and that NAT is enabled for IPv4. If your provider offers IPv6, enable it and verify the firewall rules for it.
9. Connect and test. Modem to the WAN port, a switch or an access point to the LAN port. From a client check ping, then nslookup, then a web page. After that, test with IPv6 and a port scan from the outside.
10. Harden and document. Change all default passwords, use SSH keys instead of passwords, limit the admin interface to the LAN, update the system, and export the configuration. For remote access, set up a WireGuard tunnel rather than opening the admin panel to the Internet.
11. Keep it maintained. This is the price of freedom: from now on you are the one responsible for updates. Check the project's security announcements and plan an update every few weeks.

Example 1 – an old PC with OPNsense or pfSense CE: install it from the USB stick, assign the two interfaces, and open the web interface from a computer connected to the LAN port (the default LAN address of OPNsense is 192.168.1.1; the default password is documented and must be changed immediately). From there you set the WAN type, DHCP, DNS (Unbound), and review the default firewall rules. Additional features such as VLANs, a VPN, ad blocking or intrusion detection with Suricata can be added as plugins. Be careful with the last one – more features means more things to understand and keep updated.

Example 2 – a consumer router with OpenWrt: first check that your exact model and hardware revision is in the Table of Hardware, read the page for the device and follow its installation instructions (often the image is uploaded through the original web interface). Save the original firmware and write down the configuration before flashing. After the first boot you reach the web interface (LuCI) on 192.168.1.1; set a password, configure the WAN, the Wi-Fi (WPA3/WPA2), and update the packages. A flash gone wrong can "brick" the device, so do not do this on a router you cannot afford to lose.

Example 3 – a plain Linux (e.g. Debian) as a router, for serious use: this is the most educational variant because you see every part, and with the settings below it is also suitable for daily use. It assumes a minimal Debian installation (no desktop), that wan0 is the port towards the modem and lan0 the port towards your switch, and the network plan from the VLAN and VPN section: trusted network 192.168.50.0/24 untagged on lan0, IoT on VLAN 20 (lan0.20), guests on VLAN 30 (lan0.30) and WireGuard on wg0. Adjust the names and addresses to your situation. You need the packages nftables, dnsmasq and wireguard-tools; Debian uses ifupdown by default, so to follow the interface examples below remove the entries from /etc/network/interfaces and enable systemd-networkd. If your provider uses PPPoE, the WAN interface is ppp0 instead of wan0.

1. Kernel settings – forwarding on, and a few protections against spoofed and redirected packets:

# /etc/sysctl.d/90-router.conf
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

# drop packets whose source address cannot be reached through the interface they came in on
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# ignore redirects and source routing, do not send redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# misc. hardening
net.ipv4.tcp_syncookies = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.log_martians = 1

2. Interfaces with systemd-networkd – the WAN gets its IPv4 address and an IPv6 prefix from the provider, the LAN receives an address, announces a part of that prefix to the clients, and carries the two VLANs. The exact IPv6 behaviour depends on your provider (some give a delegated prefix, some do not), so check the documentation and test it.

# /etc/systemd/network/10-wan.network
[Match]
Name=wan0

[Network]
DHCP=yes
IPv6AcceptRA=yes

# /etc/systemd/network/20-lan.network
[Match]
Name=lan0

[Network]
Address=192.168.50.1/24
VLAN=lan0.20
VLAN=lan0.30
IPv6SendRA=yes
DHCPPrefixDelegation=yes

# /etc/systemd/network/25-iot.netdev
[NetDev]
Name=lan0.20
Kind=vlan

[VLAN]
Id=20

# /etc/systemd/network/25-iot.network
[Match]
Name=lan0.20

[Network]
Address=192.168.20.1/24
IPv6SendRA=yes
DHCPPrefixDelegation=yes

# the guest VLAN (id 30, 192.168.30.1/24) is the same, with its own .netdev and .network file

3. Firewall with nftables. The router itself accepts only what it needs to offer (DNS, DHCP, SSH from the inside, WireGuard from the outside), the forwarding rules express the policy between the zones, everything else is dropped, and a rate-limited log shows what was refused. IPv6 is filtered by the same rules (the table is of the inet family), and IPv6 does not use NAT, so the firewall is its only protection.

#!/usr/sbin/nft -f
# /etc/nftables.conf
flush ruleset

define WAN     = "wan0"
define LAN     = "lan0"
define IOT     = "lan0.20"
define GUEST   = "lan0.30"
define VPN     = "wg0"
define WG_PORT = 51820

table inet filter {

  chain input {
    type filter hook input priority filter; policy drop;

    ct state invalid drop
    ct state established,related accept
    iifname "lo" accept

    # ICMP: rate limited, but IPv6 needs most of it to work at all
    icmp type { echo-request, destination-unreachable, time-exceeded, parameter-problem } limit rate 10/second accept
    icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem } accept
    icmpv6 type echo-request limit rate 10/second accept
    icmpv6 type { nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } ip6 hoplimit 255 accept

    # From the outside only: DHCP replies from the provider and WireGuard
    iifname $WAN udp sport 67 udp dport 68 accept
    iifname $WAN ip6 saddr fe80::/10 udp sport 547 udp dport 546 accept
    iifname $WAN udp dport $WG_PORT accept

    # From the inside: DNS and DHCP for everybody, SSH only from the trusted side
    iifname { $LAN, $IOT, $GUEST, $VPN } meta l4proto { tcp, udp } th dport 53 accept
    iifname { $LAN, $IOT, $GUEST } udp dport 67 accept
    iifname { $LAN, $VPN } tcp dport 22 ct state new limit rate 10/minute accept

    limit rate 5/minute log prefix "nft input drop: "
  }

  chain forward {
    type filter hook forward priority filter; policy drop;

    ct state invalid drop
    ct state established,related accept

    # PPPoE and some tunnels have a smaller MTU: adjust the TCP segment size
    oifname $WAN tcp flags syn tcp option maxseg size set rt mtu

    # IoT and guests must never reach private addresses behind the WAN (e.g. the modem's admin page)
    iifname { $IOT, $GUEST } oifname $WAN ip daddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10 } drop

    # Policy between the zones (everything not listed is dropped)
    iifname $LAN   oifname { $WAN, $IOT } accept
    iifname $IOT   oifname $WAN accept
    iifname $GUEST oifname $WAN accept
    iifname $VPN   oifname { $LAN, $WAN } accept

    limit rate 5/minute log prefix "nft forward drop: "
  }
}

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname $WAN masquerade
  }
}

4. DHCP and DNS with dnsmasq (IPv6 router advertisements are already handled by systemd-networkd above, so dnsmasq only does IPv4 DHCP and DNS):

# /etc/dnsmasq.conf
interface=lan0
interface=lan0.20
interface=lan0.30
interface=wg0
no-dhcp-interface=wg0
bind-interfaces
domain-needed
bogus-priv

dhcp-range=set:lan,192.168.50.100,192.168.50.199,12h
dhcp-range=set:iot,192.168.20.100,192.168.20.199,12h
dhcp-range=set:guest,192.168.30.100,192.168.30.199,1h

# fixed addresses for devices you want to find: MAC, name, address
dhcp-host=aa:bb:cc:dd:ee:ff,nas,192.168.50.10

Before you start the firewall, check the syntax with nft -c -f /etc/nftables.conf. Load it first by hand with nft -f /etc/nftables.conf and only when everything works enable it permanently with systemctl enable nftables; if you lock yourself out, a reboot brings you back to the state before. Do all this with a keyboard and a monitor connected to the machine, not only over SSH. Then enable the other services (systemctl enable --now systemd-networkd dnsmasq wg-quick@wg0), connect a client and watch how the pieces cooperate: the client asks for an address with DHCP, asks dnsmasq for a name, sends the packet to the router, the firewall allows it because the policy lets this zone out, and NAT rewrites the source address before the packet leaves through wan0. When the answer returns, connection tracking recognises it and sends it back. To see it live, run tcpdump on both interfaces at the same time.

Checklist before you rely on it every day:

• Keep it minimal. Install only the base system, no desktop and no unrelated services. Check what is listening with ss -tulpn; everything on that list must be there on purpose.
• SSH with keys only. In the SSH server configuration set PasswordAuthentication no and PermitRootLogin no, and allow only the users you need. The firewall already limits access to the trusted side and the VPN.
• Automatic security updates. Use unattended-upgrades and plan a reboot for kernel updates. Also keep the time correct (systemd-timesyncd or chrony), otherwise logs and certificates become unreliable.
• Back up the configuration. Everything that matters is in /etc. Keep it in version control (for example etckeeper) and store a copy on another device. With the copy you can rebuild the router on any computer in an hour.
• Test from the outside and from the inside. Scan your public IPv4 and IPv6 address from a different network (nothing but the WireGuard port should answer, and even that does not reply to a scan). From the guest network, try to reach a trusted device and the modem – both must fail. From the IoT network, try to start a connection to the trusted network – it must fail. Check DNS with a leak test and the MTU with ping -M do -s 1472 example.com.
• Test a power cut. Pull the plug and see whether the router comes back up by itself with all services and rules. A small UPS and a reliable disk (an SSD or an industrial SD/eMMC) are cheap compared to the time lost to a corrupted file system.
• Watch the logs. Look at journalctl -k | grep nft now and then. A few dropped packets from the Internet are normal background noise; a sudden flood or drops from your own networks are worth investigating.
• Think about physical access. Anyone who can touch the machine can reboot it into another system. Set a BIOS/UEFI password and a boot order that does not start from USB. Full disk encryption protects the data, but then someone has to enter the passphrase after every restart, which is usually impractical for a headless router.
• Document what you did – interface names, addresses, VLAN numbers, the provider's data and where the backup is. Future you (or someone else in the household) will be grateful.
• Keep plan B. Keep the old router configured and labelled so you can swap it in within minutes while you fix the problem.

Some resources:

• OpenWrt Documentation
• OPNsense Documentation
• pfSense Documentation
• VyOS Documentation
• nftables wiki
• ArchWiki – Router (useful for other Linux distributions too)
• WireGuard Quick Start

A Few More Thoughts

Behind the simple icon of Wi-Fi hides more than fifty years of ideas, compromises and standards. It is remarkable that a device from one manufacturer can talk to a device from another across the world only because everyone agreed on the same rules and published them. It also means that a network is never "done": the protocols change, the addresses run out, the encryption ages and the threats evolve. For a home user the most important habits are not complicated – keep the router updated, expose as little as possible, separate what you do not trust, and know what is on your network.

Building your own router is not for everyone, and a good consumer router with regular updates is a perfectly reasonable choice. But even if you never do it, trying it once on an old computer teaches more about networks than any text, including this one.