CONTENTS

SYNOPSIS

DESCRIPTION

Optionally, a preprocessor can be specified using -p preproc where pathname is to be piped through. Useful preprocessors include cpp(1) and m4(1). If preproc does not start with a slash (‘/’) as its first character, the usual PATH name search is performed. Care should be taken with this in environments where not all file systems are mounted (yet) by the time ip6fw is being run (e.g. when they are mounted over NFS). Once -p has been specified, optional -D and -U specifications can follow and will be passed on to the preprocessor. This allows for flexible configuration files (like conditionalizing them on the local hostname) and the use of macros to centralize frequently required arguments like IP addresses.

The ip6fw code works by going through the rule-list for each packet, until a match is found. All rules have two associated counters, a packet count and a byte count. These counters are updated when a packet matches the rule.

The rules are ordered by a "line-number" from 1 to 65534 that is used to order and delete rules. Rules are tried in increasing order, and the first rule that matches a packet applies. Multiple rules may share the same number and apply in the order in which they were added.

If a rule is added without a number, it is numbered 100 higher than the previous rule. If the highest defined rule number is greater than 65434, new rules are appended to the last rule.

The delete operation deletes the first rule with number number, if any.

The list command prints out the current rule set.

The show command is equivalent to ‘ip6fw -a list’.

The zero operation zeroes the counters associated with rule number number.

The flush operation removes all rules.

Any command beginning with a '#', or being all blank, is ignored.

One rule is always present:
65535 deny all from any to any

This rule is the default policy, i.e., do not allow anything at all. Your job in setting up rules is to modify this policy to match your needs.

The following options are available:

action:

If the kernel was compiled with IPV6FIREWALL_VERBOSE, then when a packet matches a rule with the "log" keyword or a clear/resetlog is performed, a message will be logged to syslogd(8), or, if that fails, to the console. If the kernel was compiled with the IPV6FIREWALL_VERBOSE_LIMIT option, then logging will cease after the number of packets specified by the option are received for that particular chain entry. When this limit is reached, the limit and rule number will be logged. Logging may then be re-enabled by clearing the packet counter for that entry.

The syslogd(8) logging and the default log limit are adjustable dynamically through the sysctl(8) interface.

proto:

src and dst:

The <address/prefixlen> may be specified as:

The sense of the match can be inverted by preceding an address with the "not" modifier, causing all other addresses to be matched instead. This does not affect the selection of port numbers.

With the TCP and UDP protocols, optional ports may be specified as:

Service names (from /etc/services) may be used instead of numeric port values. A range may only be specified as the first value, and the length of the port list is limited to IPV6_FW_MAX_PORTS (as defined in
.In netinet6/ip6_fw.h ) ports.

Fragmented packets which have a non-zero offset (i.e., not the first fragment) will never match a rule which has one or more port specifications. See the frag option for details on matching fragmented packets.

Rules can apply to packets when they are incoming, or outgoing, or both. The in keyword indicates the rule should only match incoming packets. The out keyword indicates the rule should only match outgoing packets.

To match packets going through a certain interface, specify the interface using via:

The via keyword causes the interface to always be checked. If recv or xmit is used instead of via, then the only receive or transmit interface (respectively) is checked. By specifying both, it is possible to match packets based on both receive and transmit interface, e.g.:

"ip6fw add 100 deny ip from any to any out recv ed0 xmit ed1"

The recv interface can be tested on either incoming or outgoing packets, while the xmit interface can only be tested on outgoing packets. So out is required (and in invalid) whenever xmit is used. Specifying via together with xmit or recv is invalid.

A packet may not have a receive or transmit interface: packets originating from the local host have no receive interface, while packets destined for the local host have no transmit interface.

Additional options:

CHECKLIST

• Remember that you filter both packets going in and out. Most connections need packets going in both directions.
• Remember to test very carefully. It is a good idea to be near the console when doing this.
• Do not forget the loopback interface.

FINE POINTS

If you are logged in over a network, loading the KLD version of ip6fw is probably not as straightforward as you would think ( "not supported"). I recommend this command line:
kldload ip6fw && \
ip6fw add 32000 allow all from any to any

Along the same lines, doing an
ip6fw flush

EXAMPLES

ip6fw add deny tcp from hacker.evil.org to wolf.tambov.su 23

This one disallows any connection from the entire hackers network to my host:

ip6fw add deny all from fec0::123:45:67:0/112 to my.host.org

Here is a good usage of the list command to see accounting records and timestamp information:

ip6fw -at l

or in short form without timestamps:

ip6fw -a l

HISTORY

AUTHORS

BUGS