iptables settings

Most of the iptables options can be found in the man page iptables(1) or online on the project web site at http://www.netfilter.org

Tab Compiler

Compiler

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.

Command line options for the compiler

Additional command line options for the policy compiler.

Output file name

Specify the name of the generated iptable script. If left blank, the file name is constructed from the firewall object name and extension ".fw".

Assume firewall is part of 'any'

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.

Accept TCP sessions opened prior to firewall restart

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.

Accept ESTABLISHED and RELATED packets before the first rule

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.

Drop packets that are associated with no known connection

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.

Bridging firewall

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.

Detect shadowing in policy rules

Rule shadowing happens when a certain rule is a superset 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.

Ignore empty groups in rules

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.

Enable support for NAT of locally originated connections

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.

Clamp MSS to MTU

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).

Make Tag and Classify actions terminating

Normally, iptables targets MARK and CLASSIFY are not terminating. This means iptables sets mark on the packet but does not stop inspeaction process and other rules still inspect the same packet. Fwbuilder policy compiler can emulate terminating behavior for these rules if this checkbox is checked.

Default action on "Reject"

This defines what kind of ICMP message will be send back to the sender if packet matches rule with action "Reject".

Always permit ssh access from the management station with given address

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 amke 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.


Tab Installer

Directory on the firewall where script should be installed

Installer will try to put generated script in /etc on the firewall, unless this option specify different location

User name used to authenticate to the firewall

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

Alternative name or address used to communicate with the firewall

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.

Command that installer should execute on the firewall to activate the policy

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.

Additional command line parameters to ssh

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.

External policy install script

Put the full path to your own installer script here if you have one.

Command line options for the script

Command line options to the external installer script go here.


Tab Prolog/Epilog

Prolog section

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.

Insert prolog script ...

you can control where exactly commands specified in the Prolog section will be placed:

Epilog section

Epilog commands are added at the bottom of generated script, after iptables commands.


Tab Logging

use LOG

Use target LOG for logging

log TCP seq. numbers

Available if target LOG is used for logging. Log TCP sequence numbers. This is a security risk if the log is readable by users.

log TCP options

Available if target LOG is used for logging. Log options from the TCP packet header.

log IP options

Available if target LOG is used for logging. Log options from the IP packet header.

Use numeric syslog levels

Available if target LOG is used for logging. Use numeric log levels instead of the names "debug", "info" etc. This option was added long time ago because of a bug in iptables and probably is not relevant any more.

Log level

Available if target LOG is used for logging. This option refers to the syslog log level and is used with firewalls that support logging via the syslog protocol. Here is the list of the standard log levels: ’debug’, ’info’, ’notice’, ’warning’, ’error ’, ’crit’ and ’alert'

queue threshold

Available if target ULOG is used for logging Number of packet to queue inside kernel. Setting this value to, e.g. 10 accumulates ten packets inside the kernel and transmits them as one netlink multipart message to userspace. Default is 1 (for backwards compatibility).

netlink group

Available if target ULOG is used for logging This specifies the netlink group (1-32) to which the packet is sent. Default value is 1.

Log prefix

Log records will be prefixed with a string you enter in this option. Firewall Builder supports the following macros in the log prefix that are expanded at the compile time:

Logging limit

Generated iptables rules use module "limit" to limit amout of log data they produce. You can limit logging to a given number of log records per unit of time.

Activate logging in all rules

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.


Tab Script Options

Load Modules

Compiler adds commands to load all awailable iptables modules into kernel memory.

Verify interfaces before loading firewall policy

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.

Turn debugging on in generated script

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.

Configure interfaces of the firewall machine

This option makes compiler add commands to configure ip addresses of the interfaces of the firewall according to the "Address" objects added to interfaces in the Firewall Builder GUI.

Add virtual addresses for NAT

The compiler can generate commands to add a virtual address to one of the interfaces of the firewall machine if this option is turned on. This is needed if a NAT rule uses an IP address that does not belong to any interface of the firewall. The firewall either needs the static ’published’ ARP entry for this address, or it should be added to one of the interfaces as an ’alias’ or virtual address. The policy compiler adds code to add an ’alias’ address to the interface on top of the firewall activation script.

Use iptables-restore to activate policy

If this option is turned on, compiler generates firewall script in different format and uses iptables-restore script to load it. Both all iptables commands and the call to iptables-restore to load them are parts of the generated script, you just need to exectute this script on the firewall. The advantage of this method is that operation of loading policy using iptables-restore is atomic, that is, either the whole the new policy loads into kernel memory, or none of it does. If new policy has syntax errors, it will not load. If generated secript does not use iptables-restore to activate the policy, it may load partially if there is an error in one of the rules somewhere in the middle. Using iptables-restore helps avoid this problem.


Tab IPv6

Order in which IPv4 and IPv6 rules should be generated

Compiler can place ipv6 policies before or after ipv4 rules. This option controls the order.