compiler for PF does not need to generate protocol match "proto {tcp
udp icmp}" when service object used in the NAT rule is "any". The
reason this was done this way is lost in the mist of time; it's been
like this since very early versions of fwbuilder.
GUI usability improvements: when user double clicks on a firewall
object to open it in the editor, rule set view panel switches to
the rule set of that firewall. To decide which rule set to show,
the program scans history of the objects the user opened before in
the same GUI session and shows that firewall's rule set they
opened last. If user never opened any rule sets of this firewall,
then the first Policy object is shown. See #2465.
should use "(interface)" syntax to the right of "->" in NAT rules.
This now works for all interfaces, including those that have ip
addresses in fwbuilder configuration, when interface object appears in
"Translated Source" in a nat rule. When firewall object appears in
"Translated Source", it gets replaced with a set of its interfaces
which also get translated into "-> (interface)".
single object negation in "Inbound Interface" and "Outbound
Interface" columns in compiler for iptables.
* NATCompiler_pf.cpp (compile): see #2456 Added support for single
object negation in "Interface" rule element of PF NAT rules. Now
compiler can produce PF commands such as "nat on ! em0 ... " (for
PF <4.7) or "match on ! em0 ..." (for PF >= 4.7)
* Compiler.cpp (singleObjectNegation::processNext): moved rule
processor that processes single object negation in any rule
element to the base class Compiler.
selecting New Firewall and existing firewall has interface that is
locked". Fixed GUI crash that happened on some operations if an
object in the tree was locked. For example, if the user locked an
interface of one of the firewall objects that then proceeded to
create new firewall object, the GUI would crash. The problem was
not limited to locking specifically interface objects.
When branching rule points to a rule set that has rules with Tag and
Classify options, branching should occur in mangle table even when
checkbox "create branch in mangle table" is not checked. The fix in
this change is tentative as it creates branch in chains PREROUTING,
POSTROUTING and OUTPUT. Since target CLASSIFY is only allowed in
POSTROUTING, this may create conflict. Need to test more.
type: network object that automatically matches subnets an
interface is attached to. The object can be a child of an
interface. The object is optional and is not created automatically
for all interfaces; user can add it using context menu associated
with an interface. Dialog for this object allows editing of the
name and comment. List of network addresses represented by this
object is always generated automatically. Compiler for PF
translates this object to "en0:network" construct that is
supported by PF. Compiler for iptables expands it to the list of
ipv4 and ipv6 networks defined by the addresses of the parent
interface if interface has static addresses. If interface is
confgiured as "dynamic" and has no address in fwbuilder, then
compiler treats AttachedNetworks object as run-time and uses shell
function to determine network addresses during activation of the
firewall script. Compilers for other firewall platforms always
treat this object as compile-time and abort if it is used with
dynamic interface.
should be done in PREROUTING so it can be acted on later". If a
rule has both tagging and classification options, the rule should
be split so that iptables command doing tagging goes in PREROUTING
and rule doing classification goes into POSTROUTING chain.
;
files from DTD v18 to DTD v19. This transformation finds
"PolicyRule" elements with missing "Itf" child elements and fixes
them by adding such element with a reference pointint to "any".
Fixes#2383
* fwbuilder.dtd.in: Element "Itf" (an interface) of "PolicyRule"
should be required. DTD version increment.
object is created in the middle of the "new firewall" wizard and
clicking Back creates two firewall objects". If user chose to
create new firewall object from a template and clicked Back after
choosing the template, the program actually created two firewall
objects but only one was visible in the tree.
actions per policy rule". Options "Tag", "Classify" and "Route"
work with iptables in a combination with any action. This
implementation has one restriction: option Route can not be used
in combination with options Tag or Classify and any action that is
not Continue. This is because option Route can yield rules in
PREROUTING or POSTROUTING chains that are also used by options Tag
and Classify. For this combination we create two user-defined
chains that perform routing and tagging (or classification). In
case of a terminating action both chains end with it. This means
if one matches the packet, the other is never going to see it.
Non-terminating action "Continue" does not create this problem.
This limitation may be removed in future versions of fwbuilder.
The change in UsageResolver
eliminates unnecessary scanning of all rule sets to check if the
affected rule set might be used as a branch. The program used to
scan the same objects many times.
.
tentative fix for SF bug 3169045 "Batch installer lists IPv4
address as management address". Built-in installer wanted to use
management interface address in batch mode even when alternative
address or putty session name was provided. This happens only in
batch mode install.
compiling single rule with IPv6 destination and IPv4 gateway or
interface". Routing compiler for iptables does not support ipv6 at
this time and will issue a warning when user tries to place ipv6
address or network in a routing rule. The warning does not appear
when ipv6 address is a member of a group used in the rule. Also
see #1575.
