## pf settings

Most of the pf options can be found in the man page pf.conf(5) or online http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf

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

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

For PF 4.x this option adds "flags any" parameters to rules that match TCP services. PF 4.x by default behaves as if "flags S/SA" parameter was added to all rules matching TCP services. Adding "flags any" makes rule match not only TCP packets with SYN flag set and ACK flag cleared, which is the packet that initiates the session, but also packets with any other combination of flags, including just ACK flag set. Firewall will see packets like that when session opened before firewall software was restarted and session table cleared hit it.

for PF 3.x the behavior of the policy compiler is opposite: when this option is not set, it adds "flags S/SA" to all rules that match any TCP services; if this option is set, "flags" parameter is not added to these rules at all, which makes them match TCP packets with any combination of flags.

### Modulate state for all stateful rules

This adds "modulate state" parameter to rules that match any TCP services. Quoting man pf.conf(5), section STATE MODULATION:

> Much of the security derived from TCP is attributable to how well the initial sequence numbers (ISNs) are chosen. Some popular stack implementations choose very poor ISNs and thus are normally susceptible to ISN prediction exploits. By applying a modulate state rule to a TCP connection, pf(4) will create a high quality random sequence number for each connection endpoint.

> The modulate state directive implicitly keeps state on the rule and is only applicable to TCP connections.

> For instance:

>                block all
>                pass out proto tcp from any to any modulate state
>                pass in  proto tcp from any to any port 25 flags S/SFRA modulate state

> Note that modulated connections will not recover when the state table is lost (firewall reboot, flushing the state table, etc...). pf(4) will not be able to infer a connection again after the state table flushes the connection's modulator. When the state is lost, the connection may be left dangling until the respective endpoints time out the connection. It is possible on a fast local network for the endpoints to start an ACK storm while trying to resynchronize after the loss of the modulator. The default flags settings (or a more strict equivalent) should be used on modulate state rules to prevent ACK storms.

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

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

## Tab Scrub rule options

Compiler adds rules "scrub in all [options]" and "scrub out all [options]" at the top of generated pf.conf file. This dialog tab controls options added to this rule.

### Clear DF bit

Translates into "scrub out all no-df"

From man pf.conf(5):

> Clears the dont-fragment bit from a matching IP packet. Some operating systems are known to generate fragmented packets with the dont-fragment bit set. This is particularly true with NFS. Scrub will drop such fragmented dont-fragment packets unless no-df is specified.

> Unfortunately some operating systems also generate their dont- fragment packets with a zero IP identification field. Clearing the dont-fragment bit on packets with a zero IP ID may cause deleterious results if an upstream router later fragments the packet. Using the random-id modifier (see below) is recommended in combination with the no-df modifier to ensure unique IP identifiers.

This option is only used with scrub out all rule and therefore applies to all packets sent or forwarded by the firewall.

### Use random ID

Translates into "scrub out all random-id"

From man pf.conf(5):

> Replaces the IP identification field with random values to compensate for predictable values generated by many hosts. This option only applies to packets that are not fragmented after the optional fragment reassembly.

This option is only used with scrub out all rule and therefore applies to all packets sent or forwarded by the firewall.

### Enforce Minimum TTL

Translates into "scrub out all min-ttl"

From man pf.conf(5):

> Enforces a minimum TTL for matching IP packets.

This option is only used with scrub out all rule and therefore applies to all packets sent or forwarded by the firewall.

### Enforce Maximum MSS

Translates into "scrub out all max-mss"

From man pf.conf(5):

> Enforces a maximum MSS for matching TCP packets.

This option is only used with scrub out all rule and therefore applies to all packets sent or forwarded by the firewall.

### Reassemble fragments

Enables the following three options that control fragment reassembly options.

### Buffer and reassemble fragments

Translates into "scrub in all fragment reassemble"

From man pf.conf(5):

> Using scrub rules, fragments can be reassembled by normalization. In this case, fragments are buffered until they form a complete packet, and only the completed packet is passed on to the filter. The advantage is that filter rules have to deal only with complete packets, and can ignore fragments. The drawback of caching fragments is the additional memory cost. But the full reassembly method is the only method that currently works with NAT. This is the default behavior of a scrub rule if no fragmentation modifier is supplied.

This option is only used with scrub in all rule.

### Drop duplicate fragments, do not buffer and reassemble

Translates into "scrub in all fragment crop"

From man pf.conf(5):

> The default fragment reassembly method is expensive, hence the option to crop is provided. In this case, pf(4) will track the fragments and cache a small range descriptor. Duplicate fragments are dropped and overlaps are cropped. Thus data will only occur once on the wire with ambiguities resolving to the first occurrence. Unlike the fragment reassemble modifier, fragments are not buffered, they are passed as soon as they are received. The fragment crop reassembly mechanism does not yet work with NAT.

This option is only used with scrub in all rule.

### Drop duplicate and subsequent fragments

Translates into "scrub in all fragment drop-ovl"

From man pf.conf(5):

> This option is similar to the fragment crop modifier except that all overlapping or duplicate fragments will be dropped, and all further corresponding fragments will be dropped as well.

This option is only used with scrub in all rule.

## Tab Limits

Compiler adds rule "set limit [options]" at the top of generated pf.conf file. This dialog tab controls options added to this rule.

### Reassembly pool

Translates into "set limit frags NNN"

From man pf.conf(5):

> Sets the maximum number of entries in the memory pool used for fragment reassembly (generated by scrub rules)

### State table size

Translates into "set limit states"

From man pf.conf(5):

> Sets the maximum number of entries in the memory pool used by state table entries (generated by pass rules which do not specify no state).

### Src-nodes

Translates into "set limit src-nodes"

From man pf.conf(5):

> Sets the maximum number of entries in the memory pool used for tracking source IP addresses (generated by the sticky-address and src.track options)

### Tables

Translates into "set limit tables"

From man pf.conf(5):

> Sets limits on the memory pools used by tables. "set limit tables" sets the number of tables that can exist.

### Table-entries

Translates into "set limit table-entries"

From man pf.conf(5):

> Sets limits on the memory pools used by tables. "set limit tables-entries" sets the number of addresses that can be stored in tables.

## Tab Timeouts

Compiler adds rule "set timeout [options]" at the top of generated pf.conf file. This dialog tab controls options added to this rule. See man pf.conf(5) for explanation.

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

### Insert prolog script ...

you can control where exactly commands specified in Prolog and Epilog sections will be placed:

- in the activation shell script: commands will be placed at the very beginning of the activation shell script firewall.fw
- in the pf rule file, at the very top: commands will be added at the top of the generated .conf file
- in the pf rule file, after set commands:commands will be added at the top of the generated .conf file after "set limit", "set timeout" commands but before "scrub" commands.
- in the pf rule file, after scrub commands:commands will be added at the top of the generated .conf file after "scrub" commands but before table definitions
- in the pf rule file, after scrub commands:commands will be added at the top of the generated .conf file after "table definitions" commands but before the first policy rule.

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

### Epilog section

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

## Tab Logging

### Log Prefix:

this translates into "label <text>" option in pf rules that request logging.

### Fallback "deny all" rule should log blocked packets

Compiler adds policy rule at the bottom of the pf rule set that just denies all packets in and out. This is just a fallback rule that follows best practices in firewall policy design. Normally this rule blocks but does not log packets. This option makes it log.

## Tab Script Options

### 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. Command pfctlc/ used to load PF rules into the kernel will also be given command line flag "-v".

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

### Flush pf states after reloading rules

Compiler can add command "pfctl -F states" after command "pfctl -f file.conf" to flush states that existed in memory from sessions opened prior to the policy reload. The reason is that some of these sessions might be denied by the new policy, but if state is not flushed, they will still work after the policy has been reloaded. This is optional and is off by default.

Note that ssh session used by the built-in installer to upload new pf configuration and activate it on the firewall is also subject to the state tracking and can hang if state is flushed. However, command added by the policy compiler when option "Always permit ssh access from the management station with given address" is used is immune to this. This command is written in a such way that firewall will automatically restore the state used to track ssh session opened by the installer so it will never hang. This option is located in the tab "Compiler" of the same dialog.

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