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

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 shows a visible progress bar while DNS + CIDR/range checks are running, so longer registry/network expansions are easier to follow from the admin GUI.
  • 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 removes the child's stored live-rule data so the next firewall sync can rebuild a clean ruleset.

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) can now use the same target_scope + child_ip_address_ids[] pattern when the operator wants to block all traffic for only some of the child's current IP addresses.

Current auth model

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

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