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:

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:

maximum limit of entries in the conntrack database reached

couldn't determine inverted tuple (multicast, broadcast)

kmem_cache_alloc fails (out of memory)

reply on unconfirmed connection

multicast packet (please see previous question)

icmp packet too short

icmp is fragmented

icmp checksum wrong

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.

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.

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.

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.

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.

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:

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.

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:

ACK is under the lower bound (possibly overly delayed ACK)

ACK is over the upper bound (ACKed data has never seen yet)

SEQ is under the lower bound (retransmitted already ACKed data)

SEQ is over the upper bound (over the window of the receiver)

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

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.

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.

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.