Firewall — groups#

A firewall group is a named set — of addresses, networks, ports, domains, MAC addresses or interfaces — that rules reference by name. Change the set and every rule that names it follows, which is the difference between adding one address in one place and editing nine rules. The Groups view of the Firewall page reads firewall group from the configuration tree, renders one card per group, and stages a set or delete for every member you add or remove.

The kinds#

Each kind stores its members under a different leaf. The kind you choose decides both the leaf and where the group may be referenced from.

The family column is enforced in the rule editor: an ipv6-address-group is not offered on an IPv4 rule and vice versa, because a commit that fails on that mismatch names neither the rule nor the group. interface-group is stored, displayed and editable here, but the rule editor's group selectors do not list it — ui/src/pages/Firewall.tsx GROUP_KINDS, groupOptions.

A group card#

One card per group, titled with the group's name and labelled with its kind. On it:

• The description, when the group has one.
• The members, each as a badge. Every badge has a × beside it for an operator, which stages the removal of that one member.
• includes NAME badges for any include the group declares — one group folded into another. The page shows these; it does not offer a control that creates one.
• empty when the group has neither members nor includes. An empty group is legal configuration, and a rule that references it matches nothing.
• An input and an Add button for a new member. The placeholder is the shape that kind expects. Enter adds it too.
• Delete, which stages the removal of the whole group.

The four operations a card can stage, for a group named LAN-NETS:

set firewall group network-group LAN-NETS network 198.51.100.0/24
delete firewall group network-group LAN-NETS network 198.51.100.0/24
delete firewall group network-group LAN-NETS

Creating a group#

+ Add group opens a side panel with four fields.

A group created with no members stages the bare node — set firewall group port-group WEB — so the group exists and can be filled in later.

Creating a port group for a web server, with a description:

set firewall group port-group WEB port 80
set firewall group port-group WEB port 443
set firewall group port-group WEB description 'web server ports'

Referencing a group from a rule#

In the rule editor, the group selectors sit beside the literal fields as …or source group, …or destination group and …or port group. Choosing a group disables the matching literal field, and switching between them stages the removal of whichever form is being replaced. The commands are:

set firewall ipv4 forward filter rule 20 source group network-group LAN-NETS
set firewall ipv4 forward filter rule 20 destination group port-group WEB

The whole point of the exercise is the maintenance that follows. Adding a second web server to the group is one operation, and every rule that names WEB picks it up on the same commit:

set firewall group port-group WEB port 8443

Where the data comes from#

GET /api/firewall/groups returns configOf(vyos, "firewall", "group") under a groups key — the whole firewall group subtree and nothing else (agent/opmode.go handleFirewallGroups). The route is readOnly, so any authenticated principal can read the groups; the ×, Add and Delete controls appear only for an operator, and staging is refused server-side without the operator role and a licence.

The count beside Groups in the view switcher is the total number of groups across all kinds.

See also#

• Firewall — rules — the fields that reference these groups.
• Worked rulesets — a segment-isolation ruleset built from network groups.
• Firewall — the rest of the screen.
• Use groups instead of literals — the guide.

Checked against#

ui/src/pages/Firewall.tsx, ui/src/lib/api.ts, agent/opmode.go, agent/main.go.