About | Current Status | Documentation | Performance Tests | Downloads | About Us

Which kernel version do I need?

nf-HiPAC is currently only available for linux 2.6.x. The kernel patch should apply cleanly against any kernel version >= 2.6.11. A backport to linux 2.4 is currently not planned.

Do I need to recompile my kernel? Do I have to apply any patches?

Yes, starting with nf-HiPAC version 0.8.0 you have to patch and recompile your kernel. Please have a look at the detailed installation instructions.

Can nf-HiPAC do NAT or packet mangling?

No, nf-HiPAC does not support NAT or packet mangling currently. The NAT table has to wait for the completion of the restructuring of the nat code currently taking place. After 2.6.14 this should not be a problem to implement from what we have understood. The problem currently is that the nat core nat is very tightly coupled with iptable_nat, but this is being addressed already by the Netfilter team. So NAT and packet mangling will be supported soon.

When I type 'man nf-hipac', I get 'No manual entry for nf-hipac'. What's that?

I see, you poke fun at us ;-) Now, to be honest, there is currently no man page available. We simply did not have the time to write one. This is not really a problem insofar as the man page of the nf-HiPAC userspace tool will look very much like the parts of the iptables man page that deal with 'iptables -t filter'. A short description of the commands, matches and targets can be found by typing 'nf-hipac -h'.

I get the following error when running the userspace program:
nf-hipac: error while loading shared libraries:
libnfhipac.so: cannot open shared object file: No such file or directory

This is either because you forgot to install libnfhipac or the directory to which the library has been installed is not in the search path of ldconfig. The latter can happen if you installed the library to another location than /lib or /usr/lib, e.g. /usr/local/lib. In this case the directory has to be contained in /etc/ld.so.conf. Don't forget to run ldconfig before you retry.

nf-hipac -L takes a very long time to display the rules. Why is that so?

This is because the userspace tool does a DNS lookup for each IP address. As each rule may consists of two address ranges, the worst case is four DNS lookups per rule. The problem is, if you use private IP addresses (like 10.x.x.x or 192.168.x.x), DNS is unable to resolve the hostname and times out. The sum of all these timeouts may be very long, depending on your ruleset.

Please use the -n (numeric) option for nf-HiPAC in order to prevent it from making reverse DNS lookups.

What can I do with /proc/net/nf-hipac/info ?

'cat /proc/net/nf-hipac/info' returns some general information about nf-HiPAC like memory usage and the current invocation order of nf-HiPAC and iptables.
'echo n > /proc/net/nf-hipac/info' limits the data structure to consume at most n MBytes (not bytes). It is initialized with 50% of your physical memory.
'echo nf-hipac-first > /proc/net/nf-hipac/info' makes sure that nf-HiPAC is invoked before iptables
'echo iptables-first > /proc/net/nf-hipac/info' makes sure that iptables is invoked before nf-HiPAC

What's the purpose of libnfhipac?

We developed the nf-HiPAC userspace library libnfhipac to hide some complexities of the kernel-user communication from applications. The nf-HiPAC userspace program makes use of it but it is also intended to be used by other applications like alternative userspace programs. Currently only the netlink communication is handled by the library. The application still has to construct a valid command packet which is sent to the kernel. This is rather straightforward and can be deduced by taking a look at nfhp_com.h and evt. nf-hipac-core.c. If you want to extend the library to support some command/rule construction routines, please make some suggestions.

Does nf-HiPAC have special SMP optimizations?

Our goal is to prevent blocking of packet matching under all circumstances, so we implemented all operations in a way that they don't interfere with packet matching. Let's assume you have n cpus and execute one of the mentioned operations, then n-1 cpu's don't care and are busy matching incoming packets and only 1 cpu executes the operation while it is of course possible that this cpu also handles incoming packets (like for the uniprocessor case).

Can I use nf-HiPAC for bridge firewalling?

We haven't tested it yet with linux 2.6.x and the current version of nf-HiPAC, but it shouldn't be a problem. Please note that there is a subtle difference between the iptables in and out interface match and the nf-HiPAC one if the packet arrives on the bridge. The iptables match matches if either the bridge interface name or the bridge port on which the packet arrived corresponds to the interface name stated in the rule. The nf-HiPAC match matches only if the bridge interface corresponds to the interface name in the rule. You should use the iptables physdev match to explicitly match on bridge ports when using nf-HiPAC.

What does "Rule prefix mismatch" mean?

Rules that you add to a certain user defined chain are rejected with the error "rule prefix mismatch" whenever that rules conflict 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.

I have found a new bug. What can I do?

Please send your detailed bug report to nf@hipac.org including the output of /proc/net/nf-hipac/statistics/* if possible. We are trying to fix it then.

You're telling me that nf-HiPAC can be used as a replacement for 'iptables -t filter' but what about feature xyz?

nf-HiPAC is as expressive as 'iptables -t filter' apart from some specialties described in the user guide. Anyway, if you think that some feature is missing, just tell us, but you should take a look at our TODO list first. There you can see what you can expect from upcoming versions. We are also interested in the ways you intend to use nf-HiPAC and your opinion about the project, so keep us informed.

I like your project. How can I support the development?

[Guess what, this is our favorite question ;-)]
We appreciate any kind of support. So, what can you do? Here are some ideas:

Bugs:
Please take a look at TODO/Outstanding Bugfixes first in order to see whether the bug is already known. If you found a new bug you can try to find a reproducible setup that leads to the error and send your bug report to nf@hipac.org .
Performance tests:
Have you got any experience in measuring the performance of firewalls? Please include nf-HiPAC in your next tests.
Additional documentation:
Additional documentation or updates of the existing parts are highly appreciated because we are not very good in writing documentation.
Front-ends:
You're the author of a firewall front-end, e.g. for iptables? If you want to support nf-HiPAC and you're experiencing some problems, don't hesitate to contact us.
Extensions:
nf-HiPAC does not offer an API like netfilter which can be used to write match and target extensions. We already have general support for netfilter matches and targets but we are nevertheless continuing to integrate other matches and targets directly into the algorithm as native match/target because this improves their matching performance. You can help us by telling us which matches/targets you need so that we can go and implement them as native matches, if possible. Have a look at our TODO list first.
Algorithm:
This is the hard part. Meanwhile, we believe that the code is well documented so that you can understand certain parts much better. Unfortunately, this is not sufficient to get the big picture. If you still want to hack on nf-HiPAC, please inform us about your intentions, so that we can tell you whether it is possible and in order to synchronize our work.