feat: Scope the wide area network rule to a parent network alias #4

Merged
gsadmin merged 1 commits from development into main 2026-08-18 03:04:25 +00:00

1 Commits

Author SHA1 Message Date
gsadmin 9ada3b7079 feat: Scope the wide area network rule to a parent network alias
The rule that admits a private source over the wide area network interface named
every private range as its destination as well as its source. That is wider than
the path it exists to open, which is reaching the networks behind this appliance,
and it widens further on its own as routes are added, because it permits whatever
the appliance happens to be able to route towards rather than what it is
responsible for.

The destination is now a PARENT_NETWORK_001 alias holding the parent network that
the plan resolved, so the rule is scoped to the addresses this appliance actually
owns and stays that way. The source keeps the existing RFC1918 alias, so both ends
read as what they mean rather than as literal ranges when the rule set is being
reviewed in the interface.

The alias is generated from the plan rather than written as a constant, so it
follows a parent network that was selected at random just as readily as one that
was specified.

The rule stays enabled. That was raised again and reaffirmed, and the reasoning
from when it was first enabled has not changed: the route only decides where the
host sends the packet, so shipping the rule disabled means the documented path
does not work until an operator finds and enables it. The readme continues to name
it as the first thing to disable where the upstream network is not trusted, and
that note now also records that the destination is scoped rather than open.

Verified that the alias resolves to the parent network on both a specified and a
randomly selected plan, that the rule references it, and that every alias named by
any rule in the document exists, which is a check worth having now that a rule
depends on an alias built from the plan rather than from a constant.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-17 22:37:39 -04:00