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 224.0.0.0/8
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.
So you want to build a completely transparent firewall? Great idea! Unfortunately the bridging code bypasses the normal network stack including netfilter.
But there is somebody writing a replacement for the current bridging code, have a look at http://www.math.leidenuniv.nl/~buytenh/bridge/
Please note that support for bridging firewall is considered to be highly experimental.
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.
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 500 bytes of non-swappable kernel memory!
To increase this limit to e.g. 8192, type:
echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max
Of course you can use any number which fits into an 'int' on your hardware (that is, 32bits on most popular platforms). Please note that each tracked connection needs a certain amount of non-swappable kernel memory ( 500 bytes per connection, to give you a raw number)
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
All available IP tables are listed with
cat /proc/net/ip_tables_names
Known Bug. Please update to latest CVS or use iptables >= 1.2.1 as soon as it is available.
This is because iptables does a DNS lookup for each IP address. As each rule consists out of two adresses, the worst case is two DNS lookups per rule.
The problem is, if you use private IP adresses (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.
You have to configure your sylogd apropriately: The LOG target logs to facility kernl 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 your 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).
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 -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128
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
httpd_accel_single_host off
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".