We recommend a good working knowledge of the linux networking concepts. As a short but gentle introduction you might want to read Rusty Russell's Linux Networking-concepts HOWTO at http://www.netfilter.org/documentation/HOWTO/networking-concepts-HOWTO.html .

nf-HiPAC is both syntactically and semantically identical to iptables apart from some specialties described below. There is already a lot of decent documentation available for iptables. We recommend Rusty Russell's 'Linux 2.4 Packet Filtering HOWTO' which can be downloaded at http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html and the very gentle iptables tutorial by Oskar Andreasson at http://iptables-tutorial.frozentux.net .

If you are already familiar with iptables, you shouldn't have any problems with nf-HiPAC and you should be able to start right away. For details have a look at: nf-hipac -h

It is perfectly legal to use nf-HiPAC and iptables at the same time. Currently this is necessary if you also want to do NAT or packet mangling. In this case you would use the iptables userspace tool to specify the NAT and mangle rules like you are used to by using "iptables -t nat" and "iptables -t mangle". But for the filtering rules you should instead use nf-hipac. It does not make much sense to use iptables packet filtering in conjunction with nf-HiPAC, because nf-HiPAC is as expressive as 'iptables -t filter'. For optimal performance please make sure that the iptables filtering module is not loaded and not compiled into the kernel when you are using nf-HiPAC.

Things to keep in mind when using nf-HiPAC:.

handling of jump rules containing iptables matches:

Currently we only allow some known iptables matches in jump rules. Non jump rules can contain any iptables match. Future releases of nf-HiPAC will allow any iptables match in jump rules.

no RETURN target:

nf-HiPAC does not yet support the RETURN target.

no native support for counters:

Starting with version 0.9.0 nf-HiPAC does not implement native support for counters anymore. This was done because it is not considered a good approach to enable counters for each and every rule by default. Instead counters should be selectively enabled only for those rules that require counters. The best and easiest way to implement this with nf-HiPAC is to write a new iptables target that implements counters. Any volunteer for this task?

source/destination ip match different from iptables:

nf-HiPAC doesn't support non-contiguous netmasks, e.g. /0.0.0.1 (matching every 2nd ip), whereas contiguous netmasks (prefixes), e.g. /24 or /255.255.255.0 are supported. In addition nf-HiPAC also supports arbitrary ranges.

tcp-flags match different from iptables:

nf-HiPAC can currently match only on --syn and --not-syn packets. Other tcp-flags are not supported.

state match different from iptables:

nf-HiPAC currently only supports one state match per rule and the combination of ESTABLISHED and RELATED in one rule. Other state combinations are not allowed in one rule. This can be worked around easily by adding several rules, one for each state to be matched.

ttl match different from iptables:

Instead of only supporting --ttl-eq, --ttl-lt, --ttl-gt nf-HiPAC supports arbitrary ranges.

native matches vs. iptables matches:

If there exists a native match implementation of an iptables match, the native match is always preferred. It's not possible to use the corresponding iptables match in this case.

user defined chains:

Basically nf-HiPAC user defined chains work just like iptables user defined chains. In addition nf-HiPAC implements a so called "rule prefix mismatch" protection. This means that rules that you add to a certain user defined chain are rejected with the error "rule prefix mismatch" whenever that rule conflicts with any of the rules jumping to that chain. For example let's say you have a rule that says "--source 134.96.0.0/16 -jump CHAIN1". Then nf-HiPAC will reject rules like "--source 10.0.0.1 --jump ACCEPT" in CHAIN1 with the error "rule prefix mismatch" because 10.0.0.1 lies outside of the chain prefix "134.96.0.0/16" and would therefore never match any packet. We thought that this protection would be a good idea to make sure that people use properly designed rulesets. For most people and setups this is actually true, but we had to learn that there are some setups where not allowing prefix mismatches results in more complicated rulesets. Future releases of nf-HiPAC will probably not implement this protection anymore. User defined chains in nf-HiPAC will then behave exactly as known from iptables.