Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

in /proc/net/ip_conntrack I have:

established 3076
time_wait 4346
total 7468

and in netstat I have:

established 1051
time_wait 73
total 1165

Why is that? Where are other connections? How to figure out what are they doing?

Update: Some more stats on ip_conntrack

assured 5230
unreplied 2133
total 7427
share|improve this question
Is this box acting as a router? – quanta Sep 19 '11 at 16:38
no, this is a webserver. It also has nginx as reverse-proxy so there are lots of connections on loopback interface – Poma Sep 19 '11 at 16:39
What about the netstat -nat | grep -c and grep -c /proc/net/ip_conntrack? – quanta Sep 19 '11 at 17:03
493 and 3392 respectively – Poma Sep 19 '11 at 17:23
Not that I don't want to know the answer to this as well, but were you looking into this for a particular reason? Or just exploring? – Kyle Brandt Sep 19 '11 at 17:55
up vote 2 down vote accepted

Conntrack module remembers recent connections for X seconds before they finally expire. This, in my understanding, is because iptables has several other modules that can utilize this information: for example, if you want to ban some IP address if it makes X new connections during some time frame.

netstat, on the other hand, shows real-time information and is not interested about ancient history.

Have you increased maximum amount of entries in conntrack table? With a recent-ish kernel, what does

sysctl net.ipv4.netfilter.ip_conntrack_max

... or with some older kernel,

sysctl net.ipv4.ip_conntrack_max

return to you? You may raise that value permanently via /etc/sysctl.conf or temporarily (until next reboot) via sysctl -w net.ipv4.ip_conntrack_max

share|improve this answer
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max = 65536 – Poma Sep 20 '11 at 7:27
OK. So are those "connection count limits" you are talking about related to ip_conntrack (do you see connection table full style messages in dmesg), or are you just hitting some nginx or filehandle limits? – Janne Pikkarainen Sep 20 '11 at 7:33
No, there are no connection table full messages. It can be nginx or filehandle limits, I don't know how to figure this out since I'm relatively new to linux. The main problem is described in this question:… – Poma Sep 20 '11 at 8:51

Wish I had an answer for why they differ. However, one thing to remember with a reverse proxy is that you will pay double duty in terms of conntrack for each connection. That is because you have a connection from the client to the reverse proxy, and then from the reverse proxy to the web server.

Because of this, if you already have a a stateful firewall in front, you may want to drop connection tracking all together on your reverse proxy (or perhaps on one side of it).

To drop it alltogether would be something like:

# iptables -L -t raw
target     prot opt source               destination         
NOTRACK    tcp  --  anywhere             anywhere            tcp dpt:www 
NOTRACK    tcp  --  anywhere             anywhere            tcp spt:www 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
NOTRACK    tcp  --  anywhere             anywhere            tcp spt:www 
NOTRACK    tcp  --  anywhere             anywhere            tcp dpt:www

In your case you might want to not track the loopback -i lo:

$ iptables -t raw -A PREROUTING -i lo -j NOTRACK
$ iptables -t raw -A OUTPUT -o lo -j NOTRACK
share|improve this answer
of course, if there are already NOTRACK targets in your raw table, that would by why they differ... but I suspect there is something else as far as lifetime or special loopback handling goes. – Kyle Brandt Sep 19 '11 at 18:04
My only other guess is that perhaps the difference is because of UNREPLIED vs ASSURED? – Kyle Brandt Sep 19 '11 at 18:08
I've added this stats to my question – Poma Sep 20 '11 at 13:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.