My kids lie about the internet when they argue

The only thing that really seems to matter in my children’s lives, apart from the times when they actually appreciate meeting friends and going out, is the internet. Because of that, for a long time I have used internet access as a clear tool for control: if you take care of your responsibilities, the internet is open. If you take care of nothing at all, the internet is completely shut off.

This works most of the time. The problem arises when arguments happen.

In those situations, claims often appear that the internet is absolutely necessary for schoolwork. That is not particularly likely in the middle of a school break, but it does in fact happen that school assignments need to be done even then. Sometimes it is not even about school, but about something as basic as someone needing to be able to fall asleep with audio in their headphones.

So how do you deal with it?

The simple solution is not to either shut everything down or let everything through. The solution is to limit internet access on a per-person basis.

The problem is that most off-the-shelf firewall solutions and parental control systems that can actually do this properly are often expensive, locked down, or far too coarse. DNS-based solutions are not sufficient either in a household where several people share the same connection. In that case, you need to be able to limit per individual, not per network.

That was where the need truly emerged. Not least because Emily actively tried to find loopholes to get internet access.

What I have actually built

I have built a system where each person in the household is handled individually at the network level. Each device has a fixed internal IP address and is tied to a person. Based on that, internet access can be controlled in three clear modes:

• Full access: everything is open
• Off: all traffic is completely blocked
• Limited: the internet is on, but selected services are blocked

The limited mode is the interesting one. Instead of trying to filter content via DNS or apps, firewall rules are used to block entire network blocks (CIDR ranges) for specific services such as gaming platforms and streaming. This makes it significantly harder to circumvent, because it is not enough to change DNS, an app, or a domain.

To make this manageable in practice, I have built my own control script. With a single command, I can turn internet access on, off, or limit it for a specific person or even a specific device. Status is always visible, and the system survives both reboots and network changes.

The result is that arguments like “I need the internet for school” no longer automatically mean free rein. The internet can be open where it is actually needed, while what causes the conflicts is kept out.

This is not a commercial product and not a universal solution. It is a technical response to a very everyday problem in a household where the internet has become a central part of everything.

What does it look like?

Here is a simplified picture of how it works in practice. Nothing is magical: everything is based on fixed internal IPs per device, a small state file per person, and an apply loop that installs iptables rules.

1. Fixed IPs per device (DHCP)

Each relevant device gets a fixed address in DHCP (MAC -> fixed-address). Example:

host Emily {
  hardware ethernet <mac>;
  fixed-address 10.1.1.53;
}

host SchoolEmily {
  hardware ethernet <mac>;
  fixed-address 10.1.1.51;
}

host SchoolEmily2 {
  hardware ethernet <mac>;
  fixed-address 10.1.1.52;
}

2. A configuration file with domains that can be blocked

The file /var/tornevall/system/etc/resolver/iplist.conf contains only hostnames/domains, one per line:

roblox.com
www.roblox.com
youtube.com
www.youtube.com
steamcommunity.com
store.steampowered.com

3. Resolver that turns domains into CIDR ranges

The resolver is a separate helper script called resolvecidr. Its sole purpose is to take a list of domains and translate them into entire network blocks (CIDR ranges).

This is necessary because large services use many IP addresses for redundancy and load balancing. Blocking a single IP address is practically meaningless; you have to block the entire network that the service is assigned.

The resolver works in three steps:

1. Looks up one or more IPv4 addresses for each domain
2. Runs whois on each IP address
3. Extracts the full CIDR range from the registry data

A simplified version of the script looks like this:

#!/bin/bash
set -e

CONF="/var/tornevall/system/etc/resolver/iplist.conf"
OUT="/var/tornevall/system/etc/resolver/iplist.resolved"

tmp=$(mktemp)

while read -r host; do
    [ -z "$host" ] && continue
    [[ "$host" =~ ^# ]] && continue

    for ip in $(getent ahostsv4 "$host" | awk '{print $1}'); do
        whois "$ip" | awk '/^CIDR:/ {print $2}'
    done
done < "$CONF" | tr ',' '\n' | sort -u > "$tmp"

mv "$tmp" "$OUT"

The result is written to /var/tornevall/system/etc/resolver/iplist.resolved and contains only CIDR ranges:

128.116.0.0/17
142.250.0.0/15
172.217.0.0/16
216.58.192.0/19
23.0.0.0/12

This is the list that is copied into a person’s state file when strict is activated.

4. State per person

Each person has a state file:

• /var/tornevall/system/etc/resolver/state-emily
• /var/tornevall/system/etc/resolver/state-max
• /var/tornevall/system/etc/resolver/state-thomas

An empty file means full access. Thomas = test state. You should not block yourself.

When strict is used, iplist.resolved is copied into the person’s state file.

5. Control with a single command

The script can turn access on or off per person or per device:

# Status
nethandle

# Shut down all internet for Emily
nethandle emily off

# Allow internet but block selected services (CIDR list)
nethandle emily on strict

# Only one device (Antilopen) gets strict, others can have different modes
nethandle emily-antilopen on strict

# Full access again (clears state)
nethandle emily on

6. Apply phase (iptables)

A separate apply component runs after every change and at boot. It reads the state files and creates:

• one chain per person, for example NH_EMILY
• a JUMP rule in FORWARD per internal IP that should be controlled
• DROP rules in the chain for each CIDR in the state file

Simplified, it looks like this:

Chain FORWARD
NH_EMILY all -- 10.1.1.23 0.0.0.0/0
NH_EMILY all -- 10.1.1.52 0.0.0.0/0
NH_EMILY all -- 10.1.1.51 0.0.0.0/0
NH_EMILY all -- 10.1.1.53 0.0.0.0/0

Chain NH_EMILY
DROP all -- 0.0.0.0/0 128.116.0.0/17
DROP all -- 0.0.0.0/0 142.250.0.0/15
...

The point is that the blocks become “per person” because only those specific internal IP addresses jump into the chain.