Problems at runtime


Home > FAQ > Runtime
Next Previous Contents

3. Problems at runtime

3.1 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> 224.bbb.bbb.bbb

This message is printed by the NAT code, because multicast packets are hitting the NAT table, and connection tracking doesn't handle multicast packets right now. In case you have no idea what multicast is, or don't need it at all, use:

iptables -t mangle -I PREROUTING -j DROP -d

3.2 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

My syslog or my console shows the message:

NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

This message is printed by the NAT code. It drops packets, because in order to do NAT it has to have valid connection tracking information. This message is printed for all packets for which connection tracking was unable to determine conntrack information.

Possible reasons are:

If you want to have a more detailed logging of these packets (i.e. if you suspect it are remote probe / scanning packets), use the following rule:

iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID

And yes, you have to put the rule in the mangle table, because the packets get dropped by the NAT code before they reach the filter table.

3.3 ip_conntrack: max number of expected connections N of M reached for aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

My sylog or console regularly shows messages like:

ip_conntrack: max number of expected connections N of M reached for aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

This is normally nothing to worry about, especially if N and M are 1, and the message is followed by , reusing. In particular versions of the linux kernel (2.4.19<=x<=2.4.21-pre3), this message was printed for FTP - And in fact this can happen during normal FTP operation.

With upcoming kernel versions (>=2.4.21-pre4) this message is no longer printed to not confuse the user. If you still receive messages like this, contact the http://lists.netfilter.org/mailman/listinfo/netfilter-devel mailinglist.

3.4 I'm unable to use netfilter in combination with the Linux bridging code

So you want to build a completely transparent firewall? Great idea! As of kernel 2.4.16, you still need to patch your kernel with an extra patch to get this running. You can find it at http://bridge.sourceforge.net/.

3.5 The IRC module is unable to handle DCC RESUME

Well, that's half the truth. Only the NAT module is unable to handle them. If you just use firewalling without NAT it should work fine. Patches welcome.

3.6 How does SNAT to multiple addresses work?

Netfilter tries to mangle as little as possible. So if we have a freshly- rebooted machine, and somebody behind the SNAT box opens a connection with local port 1234, the netfilter box only mangles the IP address and the port stays the same.

As soon as somebody else opens another connection with the same source port, netfilter would have to mangle IP and port if it only has a single IP for SNAT.

But if there are more than one available, it again only has to mangle the IP part.

3.7 ip_conntrack: maximum limit of XXX entries exceeded

If you notice the following message in syslog, it looks like the conntrack database doesn't have enough entries for your environment. Connection tracking by default handles up to a certain number of simultaneous connections. This number is dependent on you system's maximum memory size (at 64MB: 4096, 128MB: 8192, ...).

You can easily increase the number of maximal tracked connections, but be aware that each tracked connection eats about 350 bytes of non-swappable kernel memory!

To increase this limit to e.g. 8192, type:

echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max

To optimize performance, please also raise the number of hash buckets by using the hashsize module loadtime parameter of the ip_conntrack.o module. Please note that due to the nature of the current hashing algorithm, an even hash bucket count (and esp. values of the power of two) are a bad choice.

Example (with 1023 buckets):

modprobe ip_conntrack hashsize=1023

3.8 How do I list all tracked / masqueraded connections, similar to 'ipchains -L -M' in 2.2.x ?

There is a file in the proc-filesystem, which is called /proc/net/ip_conntrack. You can print the output of this file using

cat /proc/net/ip_conntrack

3.9 How do I list all available IP tables?

All available IP tables are listed with

cat /proc/net/ip_tables_names

3.10 iptables-save / iptables-restore from iptables-1.2 segfaults

Known Bug. Please update to latest CVS or use iptables >= 1.2.1 as soon as it is available.

3.11 iptables -L takes a very long time to display the rules

This is because iptables does a DNS lookup for each IP address. As each rule consists out of two addresses, the worst case is two 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 a 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 iptables in order to prevent it from making reverse DNS lookups.

3.12 How do I stop the LOG target from logging to my console?

You have to configure your syslogd and/or klogd appropriately: The LOG target logs to facility kern at priority warning (4). See the syslogd.conf manpage to learn more about facilities and priorities.

By default, all kernel messages at priority more severe than debug (7) are sent to the console. If you raise that to 4, instead of 7, you will make the LOG messages no longer appear on the console.

Be aware that this might also suppress other important messages from appearing on the console (does not affect syslog).

3.13 How do I build a transparent proxy using squid and iptables?

First, of course, you need a suitable DNAT or REDIRECT rule. Use REDIRECT only if squid is running on the NAT box itself. Example:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to

After that, you have to configure squid appropriately. We can only give short notes here, please refer to the squid documentation for further details.

The squid.conf for Squid 2.3 needs to be something like the following:

http_port 3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy  on
httpd_accel_uses_host_header on
Squid 2.4 needs an additional line added:

httpd_accel_single_host off

3.14 How do I use the LOG target / How can i LOG and DROP?

The LOG target is what we call a "non-terminating target", i.e. it doesn't terminate the packets rule traversal. If you use the LOG target, the packet will be logged, and rule traversal continues at the next rule.

So how do I log and drop at the same time? Nothing easier than that, you create a custom chain which contains the two rules:

iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP

Now everytime you want to log and drop a packet, you can easily use a "-j logdrop".

3.15 How do I stop worm XYZ with netfilter ?

The short answer is you cannot do that properly with netfilter. Most of the worms are using a legitimate high level protocol (i.e. HTTP, SMTP(i.e VB script attached in email), or any exploit of a vulnerability found in the daemon handling the protocol). By high level protocol, we mean above TCP/IP. As iptables does not understand these high level protocols, it's almost impossible to filter part of them out properly. For that you need application filtering proxies.

Please do not use the string match from patch-o-matic instead of application proxy filtering. It would be defeated anytime by fragmented packets (i.e. an HTTP request split on two TCP packets), by IDS evasion techniques, etc... you have been warned! The string match is useful but for different purposes.

3.16 kernel logs: Out of window data xxx

You use the tcp-window-tracking patch from patch-o-matic, which code keeps track the acceptable packets for the allowed TCP streams according to the sequence/acknowledgement numbers, segment sizes, etc of the packets. When it detects that one of the packets is not acceptable (out of the window), it marks it as INVALID and prints the message above.

Newer versions logs the packet and exactly what condition failed for it:

Also, in newer versions the logging can completely be suppressed via sysctl

echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window

3.17 Why does the connection tracking system track UNREPLIED connections with a high timeout?

First, check if you are running a 2.4.20 kernel. If yes, please apply immediately the patch from https://bugzilla.netfilter.org/cgi-bin/bugzilla/showattachment.cgi?attach_id=8! The 2.4.20 kernel did contain a bug resulting in lots of bogus UNREPLIED conntrack entries (see https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=56).

So you have read /proc/net/ip_conntrack and found UNREPLIED entries with a very high timer (can be up to five days) and are wondering why we want to waste conntrack entries with UNREPLIED entries (which are obviously not connections)?

The answer is easy: UNREPLIED entries are temporary entries, i.e. as soon as we run out of connection tracking entries (we reach /proc/sys/net/ipv4/ip_conntrack_max), we delete old UNREPLIED entries. In other words: instead of having empty conntrack entries, we'd rather keep some maybe useful information in them until we really need them.

3.18 Why isn't the 'iptables -C' (--check) option implemented?

Well, first of all, we're lazy ;). To be honest, implementing a check option is almost impossible as soon as you start to do stateful firewalling. Traditional stateless firewalling bases it's decision just on information present in the packets header. But with connection tracking (and '-m state' based rules), the outcome of the filtering decision depends on header+payload, as well as header+payload of previous packets within this connection.

3.19 Why can't i use the REJECT target in PREROUTING chains?

The REJECT target is for filtering. The filter table has got the INPUT/OUPUT/FORWARD chains, therfore the REJECT target can only be used in those chains (and sub-chains, naturally).

Netfilter users do not filter packets in the nat or mangle tables.

3.20 'iptables: Invalid argument' after kernel update (nat table)

You have just upgraded your kernel and suddenly some of the commands (especially in the 'nat' table), and you experience something like:

# iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE
iptables: Invalid argument

This happens when the structure size between kernel and userspace changes. You will need to recompile the iptables userspace program using the include files of your new kernel. This only happens if you (or the vendor of your kernel) has applied some patches either only to the old or only to the new kernel. It is not supposed to happen between vanilla kernel.org kernels. If it does, please inform the netfilter-devel mailinglist.

Next Previous Contents