3

I'm trying to understand the reason for/what do do about some weird entries I'm seeing in /proc/net/ip_conntrack on my (virtual) server. There appear to be a number of connections like this to/from my web server, in the ESTABLISHED state but with apparently huge times to live equating to several days (W = my server IP, X = IP of other party):

tcp      6 431997 ESTABLISHED src=X dst=W sport=52177 dport=80 packets=2 bytes=92 src=W dst=X sport=80 dport=52177 packets=1 bytes=48 [ASSURED] mark=0 secmark=0 use=1
tcp      6 22299 ESTABLISHED src=X dst=W sport=10975 dport=80 packets=2 bytes=92 src=W dst=X sport=80 dport=10975 packets=1 bytes=48 [ASSURED] mark=0 secmark=0 use=1

tcp      6 330236 ESTABLISHED src=W dst=X sport=80 dport=4555 packets=1 bytes=1420 [UNREPLIED] src=X dst=X sport=W dport=80 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 374668 ESTABLISHED src=W dst=X sport=80 dport=55957 packets=1 bytes=1420 [UNREPLIED] src=X dst=W sport=55957 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=1

I don't think it's malicious, and may just be some quirk of ip_conntrack, since (a) taking a random sample, these connections don't appear to show up in netstat, and (b) I can see some similar entries from my own client IP. So it looks more like it's some weirdness of how ip_conntrack works.

But I was concerned that these connections may be taking up resources, and their presence appears to make ip_conntrack unreliable. Can anyone shed any light?

Neil Coffey
  • 171
  • This seems normal. TCP is supposed to permit connections to be idle for days and then resume as if nothing happened. Why do you think this makes ip_conntrack unreliable? – David Schwartz Oct 05 '11 at 02:11
  • Sorry, by "unreliable" I meant "not giving me the information that is reliable for my particular purpose"-- my interest is partly for performance monitoring and partly for making sure "nothing untoward is going on". From what I learn, it seems that conntrack is really intended more for other purposes. – Neil Coffey Oct 05 '11 at 03:41

1 Answers1

4

This has to do with the defaults in the conntrack code. From the source:

linux-source-2.6.38/net/netfilter/nf_conntrack_proto_tcp.c:
  73 static unsigned int tcp_timeouts[TCP_CONNTRACK_MAX] __read_mostly = {
  74         [TCP_CONNTRACK_SYN_SENT]        = 2 MINS,
  75         [TCP_CONNTRACK_SYN_RECV]        = 60 SECS,
  76         [TCP_CONNTRACK_ESTABLISHED]     = 5 DAYS,
  77         [TCP_CONNTRACK_FIN_WAIT]        = 2 MINS,
  78         [TCP_CONNTRACK_CLOSE_WAIT]      = 60 SECS,
  79         [TCP_CONNTRACK_LAST_ACK]        = 30 SECS,
  80         [TCP_CONNTRACK_TIME_WAIT]       = 2 MINS,
  81         [TCP_CONNTRACK_CLOSE]           = 10 SECS,
  82         [TCP_CONNTRACK_SYN_SENT2]       = 2 MINS,
  83 };

Notice how the ESTABLISHED defaults to 5 days. Since they are ESTABLISHED I wouldn't be concerned about the resource utilization in the conntrack database, they are probably using way more resources elsewhere. From your output they look like web traffic, which in that case if you are running into resource issues you'd probably want to look at lowering the keepalive setting.

polynomial
  • 4,066
  • Thanks -- so that sort of makes sense. But if they're genuinely established, would I not expect the connections to also show up in netstat in that case? – Neil Coffey Oct 05 '11 at 02:30
  • 1
    You would except that it looks like conntrack is based on packets seen not the actual kernel states (its seems like it was built with the intent of tracking firewalls that usually won't have that in a local table). So I think if the session was established and closes poorly (like the client just goes away). I think they will stay in this state in conntrack and it looks like you may end up having to bump the total # if you run into the limit in conntrack (which I would then say is using so little resources there its worth upping the limit if you are hitting it). – polynomial Oct 05 '11 at 02:36