## 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 iptables script. If left blank, the file name is constructed from the firewall object name and extension ".fw".

### Script name on the firewall

Generated script will be copied to the firewall using this name. Can be full absolute path as well.

Installation process is controlled by several variables that the user can change in the "advanced" dialog for the firewall platform:

Tab "Compiler":

- output file name
- script name on the firewall

Tab "Installer":

- directory on the firewall where script should be installed
- command that installer should execute on the firewall

These variables have default values if input fields are left blank in the dialog:

Output file name: the name of the firewall object, plus extension ".fw".

Script name on the firewall: the same as the output file name

directory on the firewall: "/etc" (tab "Installer")

command that installer executes to activate policy: installer runs script <firewall>.fw

If user enters alternative name in the "script name on the firewall", it is used when generated script is copied to the firewall. There are two input fields in the dialogs for PF and ipf where user can enter alternative name for the .fw script and .conf file. The name can be relative or absolute path. If it is a relative path or just a file name, it is treated as a file name in the directory specified by the "directory on the firewall" input field in the "Installer" tab. If the name is an absolute path, the directory entered in "directory on the firewall..." input field is ignored. If user entered alternative name for the script on the firewall, the command that installer should execute to activate it must be entered as well. If the alternative name was entered as an absolute path, activation command should take this into account and use the same absolute path. The command can start with "sudo " if user account used to copy and activate policy is not root.

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

### 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:

- OFF: Compiler treats such case as an error and stops processing. This is because group with no objects is equivalent to an empty rule element ("source" or "destination"), but empty rule element is normally considered to be equal to "any". To avoid errors this may cause, compiler considers this situation an error.
- ON: A group with no objects in it never matches any packets, thus rendering the rule useless. When this option is turned on, compiler just throws such rule away.

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

### Add rules to accept IPv6 Neighbor Discovery packets to IPv6 policies

When this option is on, compiler will automatically add rules on top of the generated IPv6 script to permit ICMP6 types router-solicitation, router-advertisement, neighbour-solicitation, neighbour-advertisement (both INPUT and OUTPUT).

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

### Install the rule for ssh access from the management workstation when the firewall is stopped

Generated script recognizes command line arguments "start" and "stop". Running with argument "start" causes it to flush all iptables tables and rules and install rules defined in fwbuilder GUI. Running with argument "stop" causes the script to flush all tables and rules and set default policy for all chains to "DROP". This effectively shuts down the firewall for all kinds of traffic. When this option is on, compiler adds rules to permit ssh access from the address defined in the previous option even when the firewall is stopped.

## 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:

- on top of the script: commands will be placed at the very beginning, before anything else is done.
- After interface configuration: commands will be added after interface configuration is done but before any iptables commands.
- After policy reset: Policy is reset by setting default iptables targets to DROP in all tables and all chains and by purging all existing chains. If this option is chosen, prolog section goes after policy reset but before the first iptables commands.

### 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:

- %N rule number in the GUI.
- %A rule action
- %I interface the rule is associated with
- %C (iptables only) iptables chain that this rule generated code for.

### Logging limit

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.

### 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 available iptables modules into kernel memory.

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

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

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

The script generated by fwbuilder v4.0 does not rely on special labels of the addresses as it did in previous versions. Also, in the past it purged all addresses and then added those defined in fwbuilder back. Script created by fwbuilder v4.0 does not purge addresses, instead it manages them incrementally. First, it obtains the list of IP addresses of each interface and compares it with addresses defined in fwbuilder. Then, it adds missing addresses to the interface and deletes addresses that are not configured in fwbuilder.

### Clear IP addresses and bring down interfaces not configured in fwbuilder

If this option is on, generated script will clear IP addresses and bring down interfaces of the firewall that have not been configured in the fwbuilder GUI. This can be used to ensure that the configuration of the firewall machine is perfectly synchronized with objects defined in fwbuilder. This function does nothing to interfaces configured in fwbuilder, regardless of their type ("regular", "dynamic" or "unnumbered"). Be careful using this option, especially in the early stages of building fwbuilder objects for the new firewall. If you forget to add an interface that is supposed to pass traffic to fwbuilder configuration, generated script will shut it down when this option is turned on. However when configuration has been debugged and is known to be correct, it may be useful to turn this option on to make fwbuilder completely take over management of firewall interfaces.

### Configure VLAN interfaces

When this option is on, generated script will use vconfig commands to configure vlan interfaces defined in the fwbuilder GUI. The script tries to do this incrementally, that is, it compares requested set of vlans with existing vlan interfaces on the machine, then it creates those that are missing and deletes those that are not defined in fwbuilder.

### Configure bridge interfaces

When this option is on, generated script will use brctl command to manage bridge and bridge ports. This is also done incrementally, by adding bridges and ports that are configured in fwbuilder but are missing on the machine and deleting those that exist on the machine but have not been defined in fwbuilder.

### Configure bonding interfaces

When this option is on, generated script will use ifenslave command to manage bonding interfaces. The script can manage bonding interface slaves incrementally as well.

Unfortunately since bonding interfaces are created by the kernel module which is difficult to unload and load back reliably, the script can not change bonding parameters (arguments for the module) incrementally. However, the script includes commands that load "bonding" module with parameters defined in the fwbuilder GUI. The module will be loaded into the kernel with these parameters if the script runs after reboot. Bonding interface parameters are defined in the "Advanced Interface Settings" dialog of the bonding interface object.

### 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 execute 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 script 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.