o merge src+srcmask, dst+dstmask into a single field
o remove current clunky input and re-use the same javascript hooks as in MVC
o re-use OPNsense\Firewall\Api\FilterController to list available options
For tables that are purely used for presentation as opposed to data, using the role="presentation" attribute prevents extra announcements from screen readers.
Fix a nasty scroll bar bug with alias proto selector, style
and adjust all manual widths accordingly. For a strange reason
the text inputs are 2px shorter in the base forms than the modals
and the static pages so adjust the width to 346 in that case.
When multiple interfaces are selected, these will render into separate rules in which case it might not be clear what the outcome would be, specifically when choosing something else than "pass" (pass lan,wan would lead to two rules which match either lan or wan, block lan, wan would lead to random behavior for example).
For https://github.com/opnsense/core/issues/6902
The OS fingerprints are no longer maintained so reduce user
exposure and keep the feature active for the time being.
It might make sense to remove it at a later point in time if
it continues to be abandoned.
Since filter_rules_sort() is only called via front end pages, it should be safe to check if rules already have a uuid assigned and assign them if they don't. This prevents a migration and increases the change of fast adoption of the rule uuid's.
This commit adds generate_uuid() to config.inc and mimics the same behaviour as mvc models will do, if at a later point in time we would like to hook uuid's to xml attributes in other areas as well, we can simply reuse this.
It is likely a good idea to start using the uuid's in filter_core_rules_user() as labels too as this would prevent the use of the rule hash calculation (saves time and is a more stable id in most cases).
Impact of this change should be rather low as nothing depends on the uuids yet.
* per-rule adaptive timeouts
allow per-rule adaptive timeouts. 0 is possibe to disable adaptive timeouts
* Firewall / Rules - allow per-rule adaptive timeouts, small cleanups for https://github.com/opnsense/core/pull/5492
* Firewall / Rules - allow per-rule adaptive timeouts, values may be 0 as well, so "positive" should be "non-negative" for https://github.com/opnsense/core/pull/5492
Co-authored-by: kulikov-a <36099472+kulikov-a@users.noreply.github.com>
Refactor firewall edit page to allow selection of a reply-to gateway in stead of the single "disablereplyto" option. Since underscores aren't valid for gateway names,
we should be able to use __disable__ here to mark the previous "disablereplyto" setting which we can unravel when saving settings again.
Our page saves either "disablereplyto" or "reply-to" depending on selection.
o replace type ahead with tokenizer (mutli select) while here, since the type ahead needed fixes which we rather don't copy to the other firewall sections
o we might want to change the model serializeToConfig() and reload and send it to a separate function in config.inc later to ease migration later. Part of it could be separated with a callback, but it's not super needed
o hook categories into model for firewall rules
Although this isn't a great fix, we can prevent forking https://github.com/bassjobsen/Bootstrap-3-Typeahead for now and hope someone fixes the relative issue some day.
When Typeahead inputs aren't in relative containers, postition() returns the correct values, which is why our quick menu search likely still works.
The default implies to leave it that way if unsure. The ominous
warning means nothing without explanation, but the effect is
clear for people wanting to use another setting for direction:
o Egress rules filter on outbound, so half the performance passing
traffic inwards is already wasted by not dropping it on inbound.
o Egress rules cannot set policy routes since policy routes set
outbound interface on inbound and thus the decision was already
made.
Currently the direction of the traffic can only be chosen in floating rules, but in some scenario's it's much easier to create outbound rules (only inbound is supported now).
When using a lot of interfaces, which should all be allowed to access devices on one specific interface, this would save quite some rules and is easier to track for the administrator.
This feature adds direction as on option and while already changing these pages, also allow to create "non quick" rules on interfaces.
Functionally the "regular" rules would be more aligned with the "floating" rules as we have now, with the exception that you can't add multiple interfaces in a normal rule due to the inability to reorder a single rule in multiple rulesets (rules are positional).
Policy based routing on outbound rules is not supported on the interface rules for now, since it would probably lead to confusion.
The old configuration defaults still apply, when writing an entry, both quick and direction are saved as well (default quick + in).
