IPFilter uses configuration files that contain rules and rulesets. These rules determine what is filtered, how it is filtered, and other aspects of IPFilter use.

Rules are processed from top to bottom, one after the other. IPFilter does not stop comparing packets to rulesets after the first match is made. Unless interrupted, IPFilter goes through the entire ruleset and does not decide to pass or drop the packet until the last matching rule is checked. The last matching rule always takes precedence.

A simple rule file could be:

block in all
pass  in all

IPFilter checks the first rule, which is to block the packet. Then the second rule is checked, which is to pass in the packet. The last rule takes precedence, so the packet is passed on.

Several keywords can be used to establish filtering criteria. For example, the quick keyword can be added to any rule that makes the rule take action at that match. The following is an example of that keyword:

block in quick all
pass  in       all

When the quick keyword is used, the first rule is checked. Because that contains the quick keyword, action is taken (all packets are blocked). The second rule is never encountered and no packets are passed.

Several other keywords can be used to further refine the IPFilter rulesets. For example, the on keyword specifies that the data is coming in on a named interface. The out keyword can be used to filter outbound packets.

Different rules can be established to provide advanced security for your networks. For example, the keep state rule can track if a connection is established with TCP, UDP, or ICMP. When a packet arrives, an established state table is checked. The state table is a list of TCP, UDP or ICMP sessions that are automatically passed through the firewall, circumventing the entire ruleset. Because all TCP/IP sessions have a beginning, middle, and end, all that is needed is to filter the beginning of a TCP, UDP or ICMP session. Keeping state allows you to ignore the middle and end and focus on blocking or passing new sessions.

Rule groups allow you to write rulesets in a tree fashion, not as a linear list. Therefore, if a packet has no element that is involved in a rule, the rule can be skipped. Rules can be grouped by any common element that helps keep firewall flow moving: protocol, machine, netblocks or some other element specific to your environment.

See the IPFilter Based Firewalls HOWTO for complete details about keywords, rules, and rulesets.

IPFilter uses configuration files to establish the rules used for filtering. IPFilter is controlled by using a start-up script that uses a chkconfig value and specific option values:

% /etc/init.d/ipf start | stop | reload

This script is executed when the host system is first booted. It creates the IPFilter devices, loads the /etc/ipf.conf and /etc/ipnat.conf rules files (which contain examples that are commented out), and it starts the logging daemon.

The script and other options can be used to start, stop, or reload IPFilter on your IRIX system.

The on or off value in the chkconfig file determines if IPFilter will be started and if the rules files will be loaded:

% chkconfig on|off ipfilter

The following files are used to set the options for different components of IPFilter on IRIX systems:

In addition to these files, the /etc/ipf.conf file contains filtering rules and the /etc/ipnat.conf file contains port and address mappings.

% chkconfig ipfilter on
% /etc/init.d/ipf stop
% /etc/init.d/ipf start

Network Address Translation (NAT) gives an administrator the ability to connect several computers through a common external interface. In addition, another common use of NAT is to take statically allocated blocks of addresses and map many computers into this smaller address space.

See the IPFilter Based Firewalls HOWTO for complete details about setting up maps for NAT.