Home / server / Questions / 313061
Accepted
Poma
Asked: 2011-09-20 08:21:02 +0800 CST

netstat and ip_conntrack connection count differ by order of magnitude. Why?

  • 772

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
linux ubuntu networking netstat

3 Answers

  1. Best Answer

    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

    • 3

  2. 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.

    • 1

  3. 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
    • 0