Tornevall Networks

← Back to docs

Firewall live child control

Language: EN | EN | SV

Firewall live child control

Overview

Tools now includes a separate live-control layer for child/device firewall management.

This feature is intentionally separate from the older generic firewall table editor.

Use it when you need to:

  • create children/person profiles
  • attach one or more IP addresses to a child
  • attach stable schedule keys to children and child IP rows
  • maintain host/domain block lists
  • refresh resolved destination addresses
  • add selective live rules
  • apply full off / full on immediately when needed
  • store recurring full off / full on schedules in the database

Admin GUI

The live-control editor is available from:

  • /firewall
  • then Live child control

Direct page:

  • /firewall/live

The preferred selective-blocking workflow is now child-centric:

  • open one child
  • choose which host block lists should be blocked for that child from a multi-select listbox
  • choose whether the block should apply to all child IPs or only selected child IPs
  • save that selection instead of manually toggling many separate rule rows

The same /firewall/live page now also includes a runtime-routing overview block for hosts such as the gateway. That block can show:

  • the current grouped run-after route definitions published by Tools
  • a direct JSON view of the runtime config
  • a generated shell fragment intended for local run-after.d/*.conf refreshes
  • synced netplan / legacy network-interface snapshots when the shared serverinformation path is mounted on the current Tools host

Data model

The live-control layer stores state in the dedicated firewall database connection and uses these tables:

  • child
  • child_ip_addresses
  • host_block_lists
  • host_block_list_addresses
  • live_child_rules

Important behavior

  • The database stores rule input/state, not final iptables rules.
  • fwmaker remains the component that generates the actual firewall output.
  • Host names in host block lists are now refreshed into concrete block targets with a best-effort registry lookup, so Tools can store CIDR-style network ranges instead of only one resolved host IP when RDAP data exposes that network boundary.
  • Literal IP sources in host block lists now also pass through that same RDAP/network-range lookup first, so an operator can paste one IP like 128.116.21.3 and still have Tools store the wider registry-owned CIDR such as 128.116.0.0/17 when that information is available.
  • The /firewall/live host-list refresh action now starts asynchronously and exposes tracked progress/status polling, so the admin GUI stays responsive while DNS + CIDR/range checks are running.
  • Strong child rules now use explicit precedence per targeted child IP: full_block is stronger than internet_block, which is stronger than allow_only_local, regardless of the row creation order.
  • When a child is in full_block, selective host-list rules for the same targeted child IPs are ignored in generated firewall output.
  • Full on / unblock can now also target only selected child IPs; in that scoped mode Tools removes only the matching strong/selective rule data for those IP targets and keeps unrelated child-IP rules intact.

Targeting modes

Both full-off actions and selective block_host_list rules can now be aimed at either:

  • all_child_ips
  • selected_child_ips

When selected_child_ips is used, the request also carries child_ip_address_ids[] for the child IP records that should be affected.

Schedule keys and recurring schedules

The live firewall layer now also supports database-backed recurring schedules for full off / full on.

  • children can have a stable schedule_key such as max or emily
  • child IP rows can have stable schedule_key values such as max-main, max-laptop, or emily-mobile
  • recurring schedule rows then use those keys instead of hardcoded numeric ids
  • schedule writes can be globally disabled without deleting the stored rows

This allows the web GUI to keep a cron-like schedule in the database while still letting operators temporarily pause schedule writes.

API endpoints

Children

  • GET /api/firewall/children
  • POST /api/firewall/children
  • PUT /api/firewall/children/{child}
  • GET /api/firewall/children/{child}/ip-addresses
  • PUT /api/firewall/children/{child}/host-block-lists
  • POST /api/firewall/children/{child}/ip-addresses
  • PUT /api/firewall/children/{child}/ip-addresses/{ipAddress}
  • DELETE /api/firewall/children/{child}/ip-addresses/{ipAddress}
  • POST /api/firewall/children/{child}/ip-addresses/{ipAddress}/enable
  • POST /api/firewall/children/{child}/ip-addresses/{ipAddress}/disable
  • POST /api/firewall/children/{child}/block
  • POST /api/firewall/children/{child}/unblock

Children and child IP payloads can now also expose additive schedule_key fields so database-backed recurring schedules can resolve the correct logical child / device target.

Host block lists

  • GET /api/firewall/host-block-lists
  • POST /api/firewall/host-block-lists
  • PUT /api/firewall/host-block-lists/{list}
  • POST /api/firewall/host-block-lists/{list}/hosts
  • POST /api/firewall/host-block-lists/{list}/refresh
  • GET /api/firewall/host-block-lists/{list}/addresses

Child-centric selective block payload

PUT /api/firewall/children/{child}/host-block-lists

{
  "host_block_list_ids": [1, 3, 8],
  "action": "drop",
  "target_scope": "selected_child_ips",
  "child_ip_address_ids": [12, 13]
}

GET /api/firewall/children can now also include additive child-centric selection metadata so clients can render the current listbox selection directly:

  • selected_host_block_list_ids[]
  • selected_host_block_list_target_scope
  • selected_host_block_list_child_ip_address_ids[]
  • has_mixed_selective_targets

Live child rules

  • GET /api/firewall/live-child-rules
  • POST /api/firewall/live-child-rules
  • PUT /api/firewall/live-child-rules/{rule}
  • POST /api/firewall/live-child-rules/{rule}/enable
  • POST /api/firewall/live-child-rules/{rule}/disable
  • POST /api/firewall/live-child-rules/sync

Live-rule payloads can now also carry additive targeting fields:

  • target_scope
  • child_ip_address_ids[]
  • response-side target_child_ip_address_ids[]
  • response-side target_ip_addresses[]
  • response-side target_scope_summary

Full-off calls (POST /api/firewall/children/{child}/block) and full-on calls (POST /api/firewall/children/{child}/unblock) can now use the same target_scope + child_ip_address_ids[] pattern when the operator wants to change the strongest live state for only some of the child's current IP addresses.

Runtime route config

  • GET /api/firewall/runtime/{host}
  • GET /api/firewall/runtime/{host}/run-after.conf

These endpoints are intended for internal server/runtime maintenance rather than for the child-control mobile UI.

The JSON endpoint returns grouped runtime route metadata for the selected host, including the configured route groups and the target path of the generated local shell fragment.

The shell endpoint returns a ready-to-source Bash fragment that registers route groups for the local run-after.sh helper.

Current auth model

The current first implementation is intended for authenticated Tools operators with the firewall permission.

The runtime-route config endpoints can also accept a dedicated header token (X-Firewall-Config-Token) when one server needs to refresh its local generated run-after fragment without an interactive web session.

If mobile/API auth changes later, the Android AGENTS file and these docs must be updated in the same change.