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).
Ideally we want to follow NAT as well, at least for the condensed layout.
For now move the padding to a class, we can't have two ids with the same
value. Initial striping seems broken. Let the browser render initially
for now.
Also experiment with "warning" and "success" coloring to further
leaverage bootstrap magic. The colors need tweaking or reverting,
but let's just see how this looks and feels for the time being.
Hide some features on smaller layout, add magic icons to automatic
rules and change the expand drop down to the right which seems a
little more natural to operate.
The table attributes 'cellspacing' and 'cellpadding' were moved inside the style attribute via a script. However, they are not valid CSS properties, so browsers should (and do) ignore them.
This commit removes them. The 'table' class, set on most tables, should take care of proper formatting anyway.
One function to return interface and ports if that is allowed
and possible somehow. Aligns logic across all components and
makes future tweaks super easy.
On firewall_rules.php, there is no indication whether a schedule-based
rule is active. This change to the schedule icon applies the same styles
that are applied to a disabled/enabled Pass rule icon (text-muted and
text-success).
The break added to the foreach loop is needed to retain reference to the
attached schedule for the filter_get_time_based_rule_status() call