5

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
Poma
  • 1,289
  • 6
  • 22
  • 35

3 Answers3

3

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

Janne Pikkarainen
  • 31,454
  • 4
  • 56
  • 78
  • `cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max` = 65536 – Poma Sep 20 '11 at 07: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 07: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: http://serverfault.com/questions/312947/nginx-does-not-close-loopback-connections – Poma Sep 20 '11 at 08:51
1

We stumbled across this case when containers (docker) were in use.

Not sure if it helps in your case or not, but it looks like netstat -nat on the host OS will only show connections intended for the host's networking stack whereas conntrack -L will show information for both the host and all its containers.

If you run netstat -nat from inside the container involved in the connection reported by conntrack -L, you should see the connection information listed there.

matschaffer
  • 329
  • 3
  • 4
0

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
Chain PREROUTING (policy ACCEPT)
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
Kyle Brandt
  • 82,107
  • 71
  • 302
  • 444
  • 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? http://www.faqs.org/docs/iptables/theconntrackentries.html – Kyle Brandt Sep 19 '11 at 18:08
  • I've added this stats to my question – Poma Sep 20 '11 at 13:57