Glam

From John's wiki
Jump to navigation Jump to search

My server 'glam' is one of my computers in my lab.

This Raspberry Pi 4 is a Model B Rev 1.5, it used to be 'glimmer'. I use this system as my network router. It replaces 'hood'. In addition to acting as the network router this system does some DNAT port forwarding for a few services and provides DHCP services for much of the LAN, details follow.

See MicroSD for notes about disk images.

This system is running Raspberry Pi OS (64-bit) which doesn't use grub as the bootloader.

I made some notes about the reading I did while learning how to configure Raspberry Pi OS as a router, and I made some notes about how Netfilter works here: netfilter.

Commands

To watch the syslog:

$ journalctl -f

Cheatsheet

This is a summary of the network configuration. You may need to read the rest of this document in order to understand it.

IPv4

Internet router is 'watchman': 10.0.0.1/16 (attached to BLUE ethernet).

Network IPv4 Subnet Interface on 'glam' Address on 'glam' Access to Purpose
SILVER 10.4.0.0/16 N/A N/A SILVER fast point-to-point networking
GREEN 10.3.0.0/16 enx8cae4cdd8e63 10.3.0.5 GREEN, ORANGE, RED, BLUE, Internet secure network (bastion, backups, certificate authority, etc)
ORANGE 10.2.0.0/16 enx8cae4cdd44a3 10.2.0.5 ORANGE, RED, BLUE, Internet LAN, for day-to-day work
RED 10.1.0.0/16 enxfc34971ec32e 10.1.0.5 RED, BLUE, Internet lab LAN, for untrusted devices/software
BLUE 10.0.0.0/16 end0 10.0.0.5 BLUE, Internet guest network, wifi, DMZ

DNS

The ISP DNS servers are configured via DHCP, typically:

  • 111.220.1.1
  • 111.220.2.2

There are two main DNS servers on the local network:

Address Host Note DNS proxy Software Purpose
10.0.0.1 'watchman' WiFi router to ISP DNS server ASUS RT-AX88U general/reliable use
10.0.0.53 'comprehension' DNS blackhole to WiFi router dbab/dnsmasq adware/spyware blocker (can interfere with services)

DHCP

This router provides DHCP services per the following spec. The DHCP services on BLUE are provided by 'watchman'.

Network IPv4 Subnet From To DNS Gateway
GREEN 10.3.0.0/16 10.3.99.101 10.3.99.199 10.0.0.53 10.3.0.5
ORANGE 10.2.0.0/16 10.2.99.101 10.2.99.199 10.0.0.53 10.2.0.5
RED 10.1.0.0/16 10.1.99.101 10.1.99.199 10.0.0.53 10.1.0.5

DMZ

The "DMZ" host on 'watchman' points to 'glam' (10.0.0.5) and then 'glam' NATs to other hosts on the LAN. In this way public internet services are provided from the public IP address on our nbn connection.

History

For the longest time I used Smoothwall (smoothwall.org) as the router on my network. In the olden days I ran it on a bare metal system, and more recently in a VirtualBox VM.

In early 2023 I switched from using Smoothwall to using OPNSense (opnsense.org) also in a VirtualBox VM running on 'tradition'. The reason for the switch was that Smoothwall seems to be mostly unmaintained these days and friends recommended OPNSense as being a better choice.

I am now remaking my network router on this Raspberry Pi because the OPNSense router running in the VM on 'tradition' is the only thing that requires me to keep 'tradition' (which is a full ATX tower) powered on all the time. So I am hoping that when my network router is on a Raspberry Pi I will be able to keep 'tradition' switched off when it's not otherwise in use and thereby save some power (and lessen my carbon emissions and my electricity bill).

Theory

In this section I will talk briefly about the theory behind the design of the network including its Ethernet switches, cabling, and IPv4 network configuration.

One important thing to understand with this network design is that there is a one-to-one correspondence between the layer-2 (Ethernet) switched networks and the layer-3 (IP) subnets. You can't get from one layer-2 ethernet switch onto another one without being routed through layer-3.

Cabling

I've done a pretty good job of making sure that the colour of the Cat6 ethernet cables which connect my various equipment matches the colour of the subnet they are on. In addition to the silver, green, orange, red, and blue cables I have also installed some white cables which are there for emergency purposes (the white cables aren't plugged in, but they are installed so that they are easy to plug in, if there's some sort of emergency).

Defence in depth

Smoothwall had a system where you could have multiple DMZ type isolated subnets layered on each other, a form of defence in depth. There were various options for this but the one I mostly used was the three-tier one which gave me GREEN (for my LAN), ORANGE (for my DMZ), and RED (for my guest/wifi network). I carried this basic system forward when I designed my other firewall/routers including my OPNSense router 'hood' and this Raspberry Pi router 'glam' that I am building presently. But now instead of only three tiers I have four.

To be clear about this the various subnets are physically isolated (see the photos of the switches below) and the access works like this:

You're on So you can access
GREEN GREEN, ORANGE, RED, BLUE, Internet
ORANGE ORANGE, RED, BLUE, Internet
RED RED, BLUE, Internet
BLUE BLUE, Internet

The various subnets have different purposes:

Subnet Purpose
GREEN secure network (bastion, backups, certificate authority, etc)
ORANGE LAN, for day-to-day work
RED lab LAN, for untrusted devices/software
BLUE guest network, wifi

To be clear the implications are that if something on BLUE gets compromised it won't be able to start attacking things on RED, and if something on RED gets compromised it won't be able to start attacking things on ORANGE, and if something on ORANGE gets compromised it won't be able to start attacking things on GREEN. If something on GREEN gets compromised then I am fucked. :P

As I do my day-to-day work on the ORANGE subnet I don't ordinarily have access to data and services on GREEN. I need to use a physically separate terminal if I need to access things on GREEN.

Point to point

This is not relevant to my router 'glam' but I do also sometimes use point-to-point networking with Ethernet crossover cables. When I do such things I call the associated NICs the SILVER subnet. But there is no routing or switching for SILVER devices, they are simply point to point.

The main usecase for point-to-point networking is for connecting my main workstation directly to my main file server with 2.5Gbps Ethernet NICs connected via Cat6 crossover cable. Similarly for connecting my main backup server to my main file server. Such networking increases transfer speed and lessens the load on my Ethernet switches and/or router.

Subnets

The subnets work out like this:

Name IPv4 Subnet Interface on 'glam'
SILVER 10.4.0.0/16 N/A
GREEN 10.3.0.0/16 enx8cae4cdd8e63
ORANGE 10.2.0.0/16 enx8cae4cdd44a3
RED 10.1.0.0/16 enxfc34971ec32e
BLUE 10.0.0.0/16 end0

Hardware

Raspberry Pi

This Raspberry Pi is a Raspberry Pi 4 Model B Rev 1.5.

NICs

The BLUE interface is built-in Ethernet, the rest are USB through a Tendak USB Hub.

Name IPv4 Subnet Interface on 'glam' Hardware
GREEN 10.3.0.0/16 enx8cae4cdd8e63 Plugable 2.5G USB NIC
ORANGE 10.2.0.0/16 enx8cae4cdd44a3 Plugable 2.5G USB NIC
RED 10.1.0.0/16 enxfc34971ec32e USB 3.0 NIC
BLUE 10.0.0.0/16 end0 Raspberry Pi built-in Ethernet

USB Hub

The USB NICs are attached to a USB 3.0 Hub: USB 3.0 Hub, Tendak USB Hub with 4 USB 3.0 Data Ports + 1 USB Smart Charging Port and Power Supply Adapter with Individual On/Off Port Switches for PS4 Pro PS4 Slim Xbox One.

Installation

At the moment this RPi is just floating above a powerboard attached to my bookcase. It is held in place by my two favourite adhesives: blu tack and gravity. It's up there so it gets better airflow for cooling than if it were sitting on the UPS below it (as it used to) and also because the weird angles of the cables being at 90° to each other lead the previous micro HDMI adapter to snap in half, so hopefully we avoid that this time around by putting less stress on the cabling. I would like to install this better but this will do for now.

In the following photo you can see the BLUE network cable attached directly to the RPi's onboard NIC, that's the 'end0' network interface which is named differently to the others because it's not a USB device as the others are, see below.

USB NIC cabling

The following photo shows the RED (enxfc34971ec32e), ORANGE (enx8cae4cdd44a3), and GREEN (enx8cae4cdd8e63) USB NICs which are attached to 'glam' via a USB 3.0 Hub, Tendak USB Hub with 4 USB 3.0 Data Ports + 1 USB Smart Charging Port and Power Supply Adapter with Individual On/Off Port Switches for PS4 Pro PS4 Slim Xbox One.

Network switches

The following photo shows the four Ethernet switches which comprise the backbone of the wired networking in my lab. I also have an extra two RED switches on the other side of the room.

Configuration

Predictable network interface names

Predictable network interface names are enabled by default on Ubuntu but on Debian-based systems, including the Raspberry Pi OS, you need to enable them specifically.

The relevant Debian documentation is here: NetworkInterfaceNames.

The reason we need to enable predictable network interface names is that we have four different NICs attached to four different and NIC-specific Ethernet switches. If we don't enable predictable network interface names our USB NICs (of which we have three) will be randomly allocated a name such as eth1, eth2, or eth3 during boot, but the actual USB device attached will vary, and we can't have that, so we need predictable names. The predictable names for the USB NICs are based on MAC address, and the onboard NIC is handled differently, and this accounts for the discrepancy in the names of the network interfaces: USB and onboard NIC names are generated differently.

Usually you enable predictable network interface names in grub by adding a parameter to the Linux command-line, but Raspberry Pi OS does not use grub, so instead you need to enable predictable network interface names using the raspi-config ncurses application.

To enable predictable network interface names (based on MAC address for USB devices):

$ sudo raspi-config

Then: Advanced Options -> Network Interface Names -> Enable predictable network interface names (yes)

and reboot.

IPv4 configuration

$ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source /etc/network/interfaces.d/*

# 2023-11-06 jj5 - BLUE:
#
auto end0
iface end0 inet static
  address 10.0.0.5
  netmask 255.255.0.0
  gateway 10.0.0.1
  dns-nameservers 10.0.0.1

# 2023-12-22 jj5 - NEW: RED: gonna try this ASUS 2.5Gbps thing
auto enxfc34971ec32e
iface enxfc34971ec32e inet static
  address 10.1.0.5
  netmask 255.255.0.0
# 2023-11-06 jj5 - OLD: RED:
#auto enx00e099001bf7
#iface enx00e099001bf7 inet static
#  address 10.1.0.5
#  netmask 255.255.0.0
 
# 2023-11-06 jj5 - ORANGE:
#
auto enx8cae4cdd44a3
iface enx8cae4cdd44a3 inet static
  address 10.2.0.5
  netmask 255.255.0.0

# 2023-11-06 jj5 - GREEN:
#
auto enx8cae4cdd8e63
iface enx8cae4cdd8e63 inet static
  address 10.3.0.5
  netmask 255.255.0.0
$ tail -n 8 /etc/sysctl.conf
# 2023-11-06 jj5 - Disable IPv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

# 2023-11-06 jj5 - enable routing:
net.ipv4.ip_forward=1

The routing config looks like this:

root@glam:~# ip route show
default via 10.0.0.1 dev end0 onlink 
10.0.0.0/16 dev end0 proto kernel scope link src 10.0.0.5 
10.1.0.0/16 dev enxfc34971ec32e proto kernel scope link src 10.1.0.5 
10.2.0.0/16 dev enx8cae4cdd44a3 proto kernel scope link src 10.2.0.5 
10.3.0.0/16 dev enx8cae4cdd8e63 proto kernel scope link src 10.3.0.5

Netfilter configuration

# apt install iptables
# cat /usr/libexec/iptables-rules.sh
#!/bin/bash

# 2023-11-18 jj5 - abort on error...
set -euo pipefail;

##################################################################################################
# 2023-11-17 jj5 - services...
#

# 2023-11-17 jj5 - trust.jj5.net
WEB_PROXY=10.2.2.1

# 2023-11-17 jj5 - desire.staticmagic.net
SALT_MASTER=10.0.0.3

#################################################################################################
# 2023-11-17 jj5 - configuration...
#

# 2023-11-16 jj5 - default deny, can override for testing...
POLICY=DROP
#POLICY=ACCEPT

# 2023-11-18 jj5 - network interfaces...
BLUE=end0
RED=enxfc34971ec32e
ORANGE=enx8cae4cdd44a3
GREEN=enx8cae4cdd8e63

# 2023-11-18 jj5 - interface IP addresses...
BLUE_IP=10.0.0.5
RED_IP=10.1.0.5
ORANGE_IP=10.2.0.5
GREEN_IP=10.3.0.5

# 2023-11-18 jj5 - iptables executable...
iptables=/usr/sbin/iptables

#################################################################################################
# 2023-11-17 jj5 - initialisation...
#

# 2023-11-16 jj5 - begin by dropping all rules...
$iptables -F
$iptables -t nat -F

# 2023-11-16 jj5 - apply default policy...
$iptables -P INPUT $POLICY
$iptables -P OUTPUT $POLICY
$iptables -P FORWARD $POLICY

##################################################################################################
# 2023-11-16 jj5 - INPUT
#

# 2023-11-16 jj5 - allow established...
$iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# 2023-11-16 jj5 - allow incoming mDNS...
$iptables -A INPUT -p udp --dport 5353 -j ACCEPT

# 2023-11-16 jj5 - allow ping on correct interface...
$iptables -A INPUT -p icmp --icmp-type echo-request -i $BLUE   -d $BLUE_IP   -j ACCEPT
$iptables -A INPUT -p icmp --icmp-type echo-request -i $RED    -d $RED_IP    -j ACCEPT
$iptables -A INPUT -p icmp --icmp-type echo-request -i $ORANGE -d $ORANGE_IP -j ACCEPT
$iptables -A INPUT -p icmp --icmp-type echo-request -i $GREEN  -d $GREEN_IP  -j ACCEPT

# 2023-11-16 jj5 - allow SSH on GREEN (or ORANGE) interfaces...
$iptables -A INPUT -i $GREEN  -p tcp -m tcp --dport 22 -j ACCEPT
#$iptables -A INPUT -i $ORANGE -p tcp -m tcp --dport 22 -j ACCEPT

# 2023-11-16 jj5 - log dropped packet...
$iptables -A INPUT -j LOG --log-level warning --log-prefix "$POLICY INPUT: "

##################################################################################################
# 2023-11-16 jj5 - OUTPUT
#

# 2023-11-16 jj5 - allow output on any interface...
$iptables -A OUTPUT -o $BLUE   -j ACCEPT
$iptables -A OUTPUT -o $RED    -j ACCEPT
$iptables -A OUTPUT -o $ORANGE -j ACCEPT
$iptables -A OUTPUT -o $GREEN  -j ACCEPT

# 2023-11-16 jj5 - log dropped packet...
$iptables -A OUTPUT -j LOG --log-level warning --log-prefix "$POLICY OUTPUT: "

##################################################################################################
# 2023-11-16 jj5 - FORWARD
#

# 2023-11-19 jj5 - log details of fragments...
$iptables -A FORWARD -p tcp -f -j LOG --log-level error --log-prefix "TCP FRAGMENT: "
$iptables -A FORWARD -p udp -f -j LOG --log-level error --log-prefix "UDP FRAGMENT: "

# 2023-11-16 jj5 - allow established...
$iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# 2023-11-16 jj5 - BLUE:
$iptables -A FORWARD -i $BLUE   -o $BLUE   -j ACCEPT

# 2023-11-16 jj5 - RED:
$iptables -A FORWARD -i $RED    -o $BLUE   -j ACCEPT
$iptables -A FORWARD -i $RED    -o $RED    -j ACCEPT

# 2023-11-16 jj5 - ORANGE:
$iptables -A FORWARD -i $ORANGE -o $BLUE   -j ACCEPT
$iptables -A FORWARD -i $ORANGE -o $RED    -j ACCEPT
$iptables -A FORWARD -i $ORANGE -o $ORANGE -j ACCEPT

# 2023-11-16 jj5 - GREEN:
$iptables -A FORWARD -i $GREEN  -o $BLUE   -j ACCEPT
$iptables -A FORWARD -i $GREEN  -o $RED    -j ACCEPT
$iptables -A FORWARD -i $GREEN  -o $ORANGE -j ACCEPT
$iptables -A FORWARD -i $GREEN  -o $GREEN  -j ACCEPT

# 2023-11-16 jj5 - log dropped packet...
$iptables -A FORWARD -j LOG --log-level warning --log-prefix "$POLICY FORWARD: "

##################################################################################################
# 2023-11-17 jj5 - POSTROUTING
#

$iptables -t nat -A POSTROUTING -o $BLUE   -j MASQUERADE
$iptables -t nat -A POSTROUTING -o $RED    -j MASQUERADE
$iptables -t nat -A POSTROUTING -o $ORANGE -j MASQUERADE
$iptables -t nat -A POSTROUTING -o $GREEN  -j MASQUERADE

##################################################################################################
# 2023-11-17 jj5 - destination NAT
#

for port in 80 443; do

  $iptables -t nat -A PREROUTING -i $BLUE   -p tcp -d $BLUE_IP   --dport $port -j DNAT --to-destination $WEB_PROXY
  $iptables        -A FORWARD    -i $BLUE   -p tcp -d $WEB_PROXY --dport $port -j ACCEPT

  $iptables -t nat -A PREROUTING -i $RED    -p tcp -d $RED_IP    --dport $port -j DNAT --to-destination $WEB_PROXY
  $iptables        -A FORWARD    -i $RED    -p tcp -d $WEB_PROXY --dport $port -j ACCEPT

  $iptables -t nat -A PREROUTING -i $ORANGE -p tcp -d $ORANGE_IP --dport $port -j DNAT --to-destination $WEB_PROXY
  $iptables        -A FORWARD    -i $ORANGE -p tcp -d $WEB_PROXY --dport $port -j ACCEPT

done

host_list=(      \
  52.62.151.214  \
  52.64.38.144   \
  54.79.5.173    \
  54.66.169.218  \
  52.65.58.216   \
  54.153.228.137 \
  54.253.9.114   \
  52.64.112.170  \
);

for host in "${host_list[@]}"; do

  for port in 4505 4506 10113; do

    $iptables -t nat -A PREROUTING -i $BLUE -p tcp -s $host --dport $port -j DNAT --to-destination $SALT_MASTER
    $iptables        -A FORWARD    -i $BLUE -p tcp -s $host --dport $port -d $SALT_MASTER -j ACCEPT

  done

done
# chmod +x /usr/libexec/iptables-rules.sh
# cat /etc/systemd/system/iptables-rules.service
[Unit]
Description=Apply custom iptables rules

[Service]
Type=oneshot
ExecStart=/usr/libexec/iptables-rules.sh

[Install]
WantedBy=multi-user.target
# systemctl enable iptables-rules.service

DHCP configuration

# apt install isc-dhcp-server
root@glam:~# cat /etc/default/isc-dhcp-server 
# Defaults for isc-dhcp-server (sourced by /etc/init.d/isc-dhcp-server)

# Path to dhcpd's config file (default: /etc/dhcp/dhcpd.conf).
#DHCPDv4_CONF=/etc/dhcp/dhcpd.conf
#DHCPDv6_CONF=/etc/dhcp/dhcpd6.conf

# Path to dhcpd's PID file (default: /var/run/dhcpd.pid).
#DHCPDv4_PID=/var/run/dhcpd.pid
#DHCPDv6_PID=/var/run/dhcpd6.pid

# Additional options to start dhcpd with.
#       Don't use options -cf or -pf here; use DHCPD_CONF/ DHCPD_PID instead
#OPTIONS=""

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#       Separate multiple interfaces with spaces, e.g. "eth0 eth1".
# 2023-11-17 jj5 - NOTE: these are the GREEN, ORANGE, and RED interfaces
INTERFACESv4="enx8cae4cdd8e63 enx8cae4cdd44a3 enxfc34971ec32e"
INTERFACESv6=""
# cat /etc/dhcp/dhcpd.conf
root@glam:~# cat /etc/dhcp/dhcpd.conf
# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
#

# option definitions common to all supported networks...
# 2023-11-17 jj5 - we don't use these...
#option domain-name "example.org";
#option domain-name-servers ns1.example.org, ns2.example.org;

default-lease-time 600;
max-lease-time 7200;

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
# 2023-11-17 jj5 - NOTE: I don't use this because we're not authoritative on BLUE subnet
#authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
#log-facility local7;

# No service will be given on this subnet, but declaring it helps the 
# DHCP server to understand the network topology.

#subnet 10.152.187.0 netmask 255.255.255.0 {
#}

# This is a very basic subnet declaration.

#subnet 10.254.239.0 netmask 255.255.255.224 {
#  range 10.254.239.10 10.254.239.20;
#  option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
#}

# This declaration allows BOOTP clients to get dynamic addresses,
# which we don't really recommend.

#subnet 10.254.239.32 netmask 255.255.255.224 {
#  range dynamic-bootp 10.254.239.40 10.254.239.60;
#  option broadcast-address 10.254.239.31;
#  option routers rtr-239-32-1.example.org;
#}

# A slightly different configuration for an internal subnet.
#subnet 10.5.5.0 netmask 255.255.255.224 {
#  range 10.5.5.26 10.5.5.30;
#  option domain-name-servers ns1.internal.example.org;
#  option domain-name "internal.example.org";
#  option routers 10.5.5.1;
#  option broadcast-address 10.5.5.31;
#  default-lease-time 600;
#  max-lease-time 7200;
#}

# Hosts which require special configuration options can be listed in
# host statements.   If no address is specified, the address will be
# allocated dynamically (if possible), but the host-specific information
# will still come from the host declaration.

#host passacaglia {
#  hardware ethernet 0:0:c0:5d:bd:95;
#  filename "vmunix.passacaglia";
#  server-name "toccata.example.com";
#}

# Fixed IP addresses can also be specified for hosts.   These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP.   Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
# set.
#host fantasia {
#  hardware ethernet 08:00:07:26:c0:a5;
#  fixed-address fantasia.example.com;
#}

# You can declare a class of clients and then do address allocation
# based on that.   The example below shows a case where all clients
# in a certain class get addresses on the 10.17.224/24 subnet, and all
# other clients get addresses on the 10.0.29/24 subnet.

#class "foo" {
#  match if substring (option vendor-class-identifier, 0, 4) = "SUNW";
#}

#shared-network 224-29 {
#  subnet 10.17.224.0 netmask 255.255.255.0 {
#    option routers rtr-224.example.org;
#  }
#  subnet 10.0.29.0 netmask 255.255.255.0 {
#    option routers rtr-29.example.org;
#  }
#  pool {
#    allow members of "foo";
#    range 10.17.224.10 10.17.224.250;
#  }
#  pool {
#    deny members of "foo";
#    range 10.0.29.10 10.0.29.230;
#  }
#}

# 2023-11-17 jj5 - GREEN...
subnet 10.3.0.0 netmask 255.255.0.0 {
  range 10.3.99.101 10.3.99.199;
  option routers 10.3.0.5;
  option domain-name "green.dhcp.staticmagic.net";
  option domain-name-servers 10.0.0.53;
  option subnet-mask 255.255.0.0;
  option broadcast-address 10.3.255.255;
  default-lease-time 600;
  max-lease-time 7200;
}

# 2023-11-17 jj5 - ORANGE...
subnet 10.2.0.0 netmask 255.255.0.0 {
  range 10.2.99.101 10.2.99.199;
  option routers 10.2.0.5;
  option domain-name "orange.dhcp.staticmagic.net";
  option domain-name-servers 10.0.0.53;
  option subnet-mask 255.255.0.0;
  option broadcast-address 10.2.255.255;
  default-lease-time 600;
  max-lease-time 7200;
}

# 2023-11-17 jj5 - RED...
subnet 10.1.0.0 netmask 255.255.0.0 {
  range 10.1.99.101 10.1.99.199;
  option routers 10.1.0.5;
  option domain-name "red.dhcp.staticmagic.net";
  option domain-name-servers 10.0.0.53;
  option subnet-mask 255.255.0.0;
  option broadcast-address 10.1.255.255;
  default-lease-time 600;
  max-lease-time 7200;
}

# 2023-11-17 jj5 - NOTE: DHCP for the BLUE subnet is handled by the wifi router 'watchman'

Diagnostics

My mate Raz says: Useful diagnostic tools include:

  • Using the LOG target when you want to trace where a problem frame is going.
  • iptables [-t nat] -L -v -n
  • tshark -ni any icmp

You can get interface stats with:

  • ip -s a

Research

Things I found while researching the configuration for this system: