the user starts typing something into the quick filter. When the
quick filter is cleared, re-expand any items that started off
expanded (so we get the union of expanded items displayed by quick
filter plus what the user started with expanded).
that the user forgets to set a data directory on a firewall and then
refers to it from an Address Table. Made the error message a little
explicit since now the only way the error can happen is if the firewall
is missing the data directory setting.
a dynamic group are actually objects. Previously we were showing
stuff like FirewallOptions objects. To make sure that dynamic
group expansion is done the same way in the UI and for the
compiler, also fixed#2502 (consolidate logic for DynamicGroup).
There's a "data directory" setting under user preferences. If the
user selects an address table file using "choose file" and that
file is "inside" the data directory, then the appropriate part of
the path is replaced with %DATADIR% as a variable. If the address
table is marked "run-time" then the path is taken from the
firewall data directory option.
config". Compiler for PF can now preserve names of object groups,
dynamic groups, compile-time AddressTable and compile-time DNSName
objects in the generated pf.conf file. This is optional and is
controlled by a checkbox in the firewall settings dialog.
"reply-to" and "dup-to" options in both pre-4.7 and 4.7 formats. In PF
4.7 these parameters moved to the end of the rule and are now part of
the "filteropts" block of parameters.
follows source routing rule options "route-to", "reply-to" and
"dup-to". Also, since currently fwbuilder does not support source
routing rules with multiple different interface-gateway pairs (only
one interface in combination with one or multiple gateway addresses
are supported), importer displays warning and marks rules as "broken"
when it encounters this configuration.
macros". Importer now records all parser errors in the comments of
rules where they occurred and marks these rules "broken" by coloring
them red. Behavior on import of pf.conf file with undefined macros is
inconsistent at this time: undefined macro that appears in a rule
where parser expects ip addresses is converted to a run-time DNSName
object with name "$macro", a warning is displayed and rule is marked
as "broken". Undefined macro in the position of interface name, port
name or other parameters triggers generic parser error that looks like
"Parser error: line 26:19: unexpected token: $ext". The rule is marked
as "broken" and the error is recorded in the comment.
ignored". Since we can not import address lists or tables that contain
a mix of negated and non-negated items, importer should display an
error when it enounters one of these and mark all rules that use it as
"broken" (rule is colored red and error message is added to the
comment).
macros". If pf.conf file uses an undefined macro (there is $macro
somewhere but the macro has never been defined), importer issues a
warning, creates run-time DNSName object with the name "$macro" and
marks all rules where it is used as broken, that is, rules are colored
red and the error message is added to the comment field. Using
run-time DNSName object makes compiler use "$macro" in the generated
pf rule which means fwbuilder generates exactly the same pf rule as
the one it tried to import.
where possible". Importer for PF recognizes macros that define lists
of ip addresses, interfaces or host names and creates object groups
with the same name from them. Only macros that contain at least one
ip address in the list are recognized.
