Full path to the policy compiler executable. Use this if you do not want to use standard Firewall Builder policy compiler that comes with the package or if you want to wrap compiler in a script.
Additional command line options for the policy compiler.
Specify the name of the generated iptables script. If left blank, the file name is constructed from the firewall object name and extension ".fw".
On some firewall platforms there is a difference in the configuration command used to control access through the firewall versus the command that controls access to the firewall itself. For example, in iptables, packets headed for the firewall machine should be inspected in the INPUT chain, while packets going through the firewall are inspected in the FORWARD chain. If this option is ON, the compiler generates code for both FORWARD and INPUT chains if it sees ’any’ as the destination of the policy rule. In other words, it assumes that the firewall is part of ’any’, and packets may either go to or through the firewall. If this option is off, the compiler only generates code for the FORWARD chain. Compiler treats ’any’ in the source of the rule in a similar way, generating code either for the OUTPUT and FORWARD, or only for the FORWARD chain.
If this option is ON, the firewall will accept TCP sessions opened before the firewall software has been activated. These sessions are special because the firewall never saw their initiation phase. If this option is on, the firewall creates an entry in the state table when it sees a packet that apparently belongs to the unknown TCP session.
This option generates an implicit rule to accept ESTABLISHED and RELATED packets before the very first rule specified in the GUI. This helps to reduce the size of the policy script generated by the policy compiler. ESTABLISHED packets are basically reply packets coming back from the server to the client. Iptables keeps state information about each TCP session opened through the firewall and thus can detect and permit these kind of packets automatically. RELATED packets belong to another stream somehow associated with the initial stream opened through the firewall. FTP protocol is a good example of this situation. FTP uses two TCP sessions: command channel and data channel. You do not need to add a special rule for the data channel to your policy because iptables ’understands’ when it needs to permit packets that belong to the data channel that has been created per request sent via a known command channel. This option is ON by default. If for some reason you do not want to have an implicit rule to permit these types of packets on top of all the rules defined in the GUI, you should uncheck this option. Remember that in this case you need to add a rule to permit these types of packets yourself. You can use the Custom Service object named ’ESTABLISHED’ in this rule. This service object can be found in the ’Standard’ object tree.
Add rule on top of the policy to match packets in state "INVALID" and drop them. This is implemented using iptables module state with option "--state INVALID". Additional checkbox makes generated script drop and log such packets.
This option changes algorithms used by the policy compiler and makes it generate script for a bridging firewall. A bridging firewall treats broadcast packets differently, never uses INPUT and OUTPUT chains, and has some other differences.
Rule shadowing happens when a certain rule is a super set of a subsequent rule and any packets potentially matched by the subsequent rule have already been matched by the prior rule. For example, if rule #1 uses the network object for the source and rule #2 uses the host object located on that network for the source, rule #1 ’shadows’ rule #2 because any packet matched by #1 will never be matched by #2. This may be important if, say, rule #1 permits and #2 denies access to the same destination. If rule #1 ’shadows’ rule #2, then rule #2 will never fire. This situation is most often an error; the compiler can detect it and abort processing of the policy with an appropriate error message.
Compiler supports special case when empty group is used in the policy rule and there are no other objects in the same rule element. Depending on the state of this option, it generates iptables commands as follows:
This is useful when one needs to control access to/from a group of hosts which may change and sometimes becomes empty. When this option is turned on, compiler will automatically disable the rule if the group becomes empty. Group contents can be managed manually or by a script using fwbedit command line tool.
By default sessions initiated by the firewall are not considered subject to NAT and NAT rules are not placed in the OUTPUT chain. However if this option is checked, compiler finds NAT rules that can match sessions initiated by the firewall and places them in the OUTPUT chain as well.
This adds a rule on top of the policy with iptables target TCPMSS and option --clamp-mss-to-pmtu which automatically clamps MSS value to (path_MTU - 40). This iptables rule is added only if IP forwarding is turned on in the host settings dialog. since IP forwarding for ipv4 and ipv6 can be configured separately, rules with target TCPMSS for iptables and ip6tables are also added separately if corresponding IP forwarding setting is enabled. Finally, this target is only available in ip6tables starting with version 1.3.8 and compiler will not add it to the generated script if version is set to less than "1.4.x" in the firewall object dialog.
Normally, iptables targets MARK and CLASSIFY are not terminating. This means iptables sets mark on the packet but does not stop inspection process and other rules still inspect the same packet. Fwbuilder policy compiler can emulate terminating behavior for these rules if this checkbox is checked.
This defines what kind of ICMP message will be send back to the sender if packet matches rule with action "Reject".
When this option is checked, compiler adds rules to permit ssh
access to the firewall from the specified address block. Rules are
placed at the very beginning of the policy to make sure ssh access
is permitted even if there is an error in the policy which otherwise
would block it. Added rules permit packets that match both NEW and
ESTABLISHED states to avoid breaking ssh sessions that were already
established.
Installer will try to put generated script in /etc on the firewall,
unless this option specify different location
This can be root or any regular user name. See "How to use built-in policy installer" on the web site at http://www.fwbuilder.org/guides/firewall_builder_howtos.html
Normally installer uses address of the interface marked as
"management" to communicate with the firewall. Note that installer
uses IP address rather than run DNS query for its name. You can
specify different IP address in this option if necessary.
If this option is blank, installer copies script produces by the
policy compiler to the firewall and executes it there. If this
option defines different command, installer copies generated script
and then runs this command.
This can be useful if you want to use alternative port for the ssh
session to the firewall. Just put "-p PORT" here and this option
will be appended to the ssh command line.
Put the full path to your own installer script here if you have one.
Command line options to the external installer script go here.
Add commands that you want compiler to insert into generated script
here. Prolog section is added at the beginning of the script, before
generated iptables commands. Note that generated iptables script is
just a shell script, so commands you place in the Prolog and Epilog
sections should be valid Bourne shell commands.
Generated iptables rules use module "limit" to limit amount of log
data they produce. You can limit logging to a given number of log
records per unit of time.
This makes all rules log, regardless of whether a rule requested
logging or not. This may be useful for debugging but produces a lot
of syslog data and should be used carefully.
this option makes compiler add commands to check if all interfaces
defined in the firewall object in the GUI really exist on the
firewall machine. Generated policy is probably going to be incorrect
and won't load because of iptables errors if it was generated for an
interface that does not really exist.
This option makes the generated firewall script print all commands
when it is executed. To do this, compiler adds "-x" to the shell
command line at the top of the script.
Compiler can place ipv6 policies before or after ipv4 rules. This
option controls the order.
Tab Installer
Directory on the firewall where script should be installed
User name used to authenticate to the firewall
Alternative name or address used to communicate with the firewall
Command that installer should execute on the firewall to activate the policy
Additional command line parameters to ssh
External policy install script
Command line options for the script
Tab Prolog/Epilog
Prolog section
Epilog section
Logging limit
Activate logging in all rules
Tab Script Options
Verify interfaces before loading firewall policy
Turn debugging on in generated script
Tab IPv6
Order in which IPv4 and IPv6 rules should be generated