Tag Info

Hot answers tagged

3

I think that sysctl parameter is for viewing only. You'll want to use the /sys/module/nf_conntrack/parameters/hashsize interface for runtime changes, and the hashsize module option to set it during initial module load. You'd want an entry in a /etc/modprobe.d/ file that looks something like this: options nf_conntrack hashsize=XXXXX


3

Xen must be NATting connections to your domU server, and the sheer number of connections is overwhelming the kernel's ability to keep track of them. While you could increase the space allocated to tracking the connections by increasing nf_conntrack_max, you would probably be better off with bridged networking instead of NAT. That way, the domU server gets ...


2

Further to Andrew B's answer: For some reason, the RHEL documentation recommends putting an executable shell script with a name like nf_conntrack_hashsize.modules extension into /etc/sysconfig/modules instead. I have no idea why. Contents would look like: #!/bin/sh exec /sbin/modprobe nf_conntrack hashsize=262144


2

I was a little curious about this one and found a pretty good explanation for your symptons. They are well described in nf_conntrack: table full - how the absence of rules can lead to unexpected behaviour. TL;DR: Just running iptables -t nat -vnL starts loading the nf_conntrack module, resulting to get unintended stateful firewalling. I haven't verified ...


2

The conntrack tool won't return a flow because, by the time your ping command has ended the flow has been terminated. Create a persistent TCP connection to something on the Internet and do a conntrack -L and you'll see a flow. You could also send some ping requests to an Internet host that doesn't respond-- you'll see a flow created (waiting for the ICMP ...


1

iptables -A INPUT -p tcp ! --syn -j ACCEPT will allow any non-SYN TCP packets through. It doesn't give you RELATED (viz. connections allowed because of other connections, eg. ftp->ftp-data), nor does it drop connections that weren't properly ESTABLISHED, but linux won't do anything with it if it is unexpected -- it gets dropped to the floor. If you need UDP, ...


1

This is from experience - I haven't done research to verify this information: I have seen a few systems where this same error is in the system logs and there is nothing in /proc/sys/net/ipv4/ip_conn* or /proc/sys/net/ipv4/netfilter. I would also like to know why - but that dosn't remain very important once you find a fix for the original symptoms. ;) The ...


1

If you don't actually need NetFilter connection tracking, I'd suggest you either disable nf_conntrack altogether (by unloading it), or add a NOTRACK rule to the top of your iptables ruleset.


1

It looks like your connection tracking table is filling up. Removing iptables rules which use connection tracking would solve the problem. If that is not an option and you have RAM available you can increase the table size: cat /proc/sys/net/netfilter/nf_conntrack_max echo 131072 > /proc/sys/net/netfilter/nf_conntrack_max You should probably increase ...


1

From iptables-extensions(8): The "net.netfilter.nf_conntrack_acct" sysctl flag controls whether new connections will be byte/packet counted. Existing connection flows will not be gaining/losing a/the accounting structure when be sysctl flag is flipped. This accounting information can then be used to create rules for the connbytes netfilter module. ...


1

Reference: conntrack man page The connection tracking system maintains two different tables, one for tracking connections that are active the other for tracking connections that are /expected/ to be active. An example of an expected connection would be an FTP connection, which uses both a control connection and a data connection. When the control connection ...



Only top voted, non community-wiki answers of a minimum length are eligible