Firewall: NAT: Port Forward - refactor to MVC (work in progress) for https://github.com/opnsense/core/issues/8401
Add a model wrapper around nat/rule and align filter code to generate the same output when using the model.
To test this part, make a copy of /tmp/rules.debug, run migrations (/usr/local/opnsense/mvc/script/run_migrations.php) and execute rule generation via /usr/local/etc/rc.filter_configure
A diff between the newly generated rules.debug and the backup created earlier should show no differences.
The following notes apply:
o ipprotocol and protocol have no defaults set as old frontend code didn't enforce this, we should likely set defaults (inet, any) knowing this will show a small diff in the output
o registerForwardRule() replaces the array_merge with an !empty() compare per field as our defaults are empty instead of missing
o legacyMoveAddressFields() in Rule.php assumes any when network and address are not set, which should comply with frontend logic as "any" is set in these cases anyway
o source/destinations are converted inline, using a volatile field to trigger the initial load (as only one is used, we prefer network)
System: Gateways: Group - a bit of an experiment for https://github.com/opnsense/core/issues/9442
Since 2023 we have refactored the gateways to MVC, which made ipprotocol part of the output, this eases validation a bit.
The route-to statement can either contain multiple `(if gwip)` entries or multiple `if` entries, but not combined.
This change keeps track of which entries are being added to the route-to statement and ignores the ones that can't be combined.
Let's put this to a test on master for a while.
In the long run the gateway group page should validate these situations to decrease the chance of gateways being silently ignored, but not before a migration to MVC.
Firewall: NAT: Port Forward - refactor to MVC (work in progress) for https://github.com/opnsense/core/issues/8401
Add a model wrapper around nat/rule and align filter code to generate the same output when using the model.
To test this part, make a copy of /tmp/rules.debug, run migrations (/usr/local/opnsense/mvc/script/run_migrations.php) and execute rule generation via /usr/local/etc/rc.filter_configure
A diff between the newly generated rules.debug and the backup created earlier should show no differences.
The following notes apply:
o ipprotocol and protocol have no defaults set as old frontend code didn't enforce this, we should likely set defaults (inet, any) knowing this will show a small diff in the output
o registerForwardRule() replaces the array_merge with an !empty() compare per field as our defaults are empty instead of missing
o legacyMoveAddressFields() in Rule.php assumes any when network and address are not set, which should comply with frontend logic as "any" is set in these cases anyway
o source/destinations are converted inline, using a volatile field to trigger the initial load (as only one is used, we prefer network)
unbound: notify user if a blocklist reset is required
This isn't perfect, as it can potentially take a while
for unbound to notice the change, keeping the notification
around longer than necessary. Additionally, this should be
a banner as well, but the banner isn't clickable in the current
state and the banner scope should ideally be separated from the
notification scope. To be continued.
