This section covers general netfilter (and non-netfilter) related questions we've encountered frequently on the mailing list.
Netfilter and IPtables are integrated in the Linux 2.4.x kernel series. Please obtain a recent kernel from http://www.kernel.org/ or one of its mirrors.
The userspace tool 'iptables' is available at the netfilter homepage on one of the mirrors at http://www.netfilter.org/, http://www.iptables.org/, http://netfilter.samba.org/, http://netfilter.gnumonks.org/ or http://netfilter.filewatcher.org/.
No, there currently is none. But if anybody wants to start, it shouldn't be too difficult because of the clean interface to the network stack.
Please inform us about any work in this area.
If you are used to masquerading on a Linux 2.2 box, you always used the ip_masq_icq module in order to get direct client-to-client ICQ working.
Nobody re-implemented this module for netfilter, because the ICQ protocol is too ugly :) But I guess it's just a matter of time until one is available.
Rusty once pointed out that only modules for protocols with at least one free client and one free server are going to get integrated into the main netfilter distribution. As for ICQ, there are only free clients, so it doesn't match this criteria. (free as in freedom, not in free beer, i.e. RMS' definition)
Some of them are not required, and some haven't been ported to netfilter yet. Netfilter does full connection tracking even for UDP, and has a policy of trying to disturb the packets at little as possible, so sometimes things `just work'.
The 2.4.x kernels is a stable release, so we can't just submit our current development into the mainstream kernel. All our code is developed and tested in netfilter patch-o-matic first. If you want to use any of the bleeding-edge netfilter functions, you may have to apply one or more of the patches from patch-o-matic. You can find patch-o-matic in the latest iptables package (or of course CVS), to be downloaded from the netfilter homepage.
patch-o-matic now has three different options:
The first one is just to make sure all important bugfixes (which have been submitted to the kernel maintainers anyway) are applied to your kernel. The second `most-of-pom` additionally prompts you for all new features which can be applied without conflict. The third option `patch-o-matic` is for real experts who want to see all the patches - but be aware, they might conflict which each other.
patch-o-matic has a neat user interface. Just enter
make most-of-pom (or pending-patches or patch-o-matic, see above)
or, if your kernel tree is not in /usr/src/linux then use
make KERNEL_DIR={your-kernel-dir} most-of-pom
in the top directory of the iptables-package. patch-o-matic checks for each of the patches if it would apply against the kernel source you have installed. If a patch would apply, you will see a little prompt, where you can ask for more information about this patch, apply the patch, skip to the next one, ...
For more information about patch-o-matic, please see the netfilter extensions HOWTO, to be found at http://www.netfilter.org/documentation/index.html#HOWTO
ipnatctl was used to set up your NAT rules from userspace in a very early development revision of netfilter during the 2.3.x kernels. It is no longer needed, thus no longer available. All of its functionality is provided by iptables itself. Have a look at the NAT HOWTO on the Netfilter homepage.
No, the NAT core does not support any kind of IPv6 or IPv6/IPv4 NAT.
The SIP (Session Initiation Protocol) is quite complex, especially getting it acrosss firewalls and NAT devices. The initial proposal was a proxy communicating over FCP (Firewall Control Protocol) with the packet filter. Now an IETF MIDCOM working group has been founded, ... meanwhile, people want to use SIP.
The netfilter/iptables team has currently no resources to implement SIP conntrack/NAT support, but we're always open for sponsors :)
The answer is a clear 'yes' and 'no'.
If you are thinking about a full failover, while all the state information is preserved: Not really. Doing state synchronization between multiple nodes is a difficult process. Harald (of the netfilter core team) has published a paper about this, but not yet found any sponsor to fund the development. Meanwhile, you can try to use our 'connection pickup' feature, which [after a failover] tries to pick up already established connections: Might be sufficient depending on the requirements.
If you do NAT and want to preserve your NAT mappings: No.
If you do statless packet filtering: Yes