In large networks with many zones where simple allow/deny rules are not sufficient,
zones become tedious to manage. Many use cases can be simplified by providing an
ability to define a default ruleset for traffic from other zones. This change proposes
adding the follwing syntax:
set firewall zone <name> default_firewall name <name>
set firewall zone <name> default_firewall ipv6_name <name>
The proposed behavior is the following:
local in:
– The default firewall ruleset for the local zone will be appended after all
from configurations.
local out:
– If a non-local zone does not have a from local ruleset but does have a
default_firewall ruleset, the default_firewall ruleset will be appended using
oifname
forward:
– The default firewall ruleset for the zone will be appended after all from
configurations
To keep the behavior consistent with from ruleset configurations, a return is appended
after the default_firewall ruleset.
The proposed behavior differs slightly from the default_policy configuration for the
local out chains. The default_policy applied in the out templates comes from the local
zone, not the actual outbound zone. The proposed change does not amend this, but does
make default_firewall logically consistent with the intent of the out rules.
Looking for some guidance here. I don’t assume the VyOS maintainers accept any and all contributions just because someone shows up with a PR Should I create a task and PR for this? Any discussion/adjustments to the intent needed? Thanks!
In my experience, the maintainers are great about accepting PRs. At a minimum, there’s a good chance that it gets added to current. Whether it gets added to LTS or not will be another story.
I’d just start with creating a task and then asking for feedback in there. If you provide a solid use case, they’re usually pretty great about merging.
If you haven’t already, check out the contributing guidelines to avoid any gotchas:
It looks like you just recently signed the CLA, so that was likely, at least in part, holding up any reviews. Make sure you link the task in the related tasks section of the PR message.
As far as the linter checks, I wouldn’t worry about them too much. As you saw, a number of them (particularly in smoke tests) are nonsensical. If the maintainers see any egregious linter oversights, I’m sure they’ll let you know.
Should I create a task and PR for this? Any discussion/adjustments to the intent needed? Thanks!