# KERNEL Conntrack system reporting wrongly

## sque

Hi I have setup a gentoo machine with kernel 2.6.16-r7 (from gentoo sources). This machine works as nat router.

The problem is that at /proc/net/ip_conntrack connections are reported as ESTABLISHED rather than SYN_SET

e.g. (an entry from /proc/net/ip_conntrack):

```
tcp      6 430878 ESTABLISHED src=192.168.0.50 dst=213.194.0.112 sport=63736 dport=80 packets=1 bytes=40 [UNREPLIED] src=213.194.0.112 dst=192.168.1.1 sport=80 dport=63736 packets=0 bytes=0 mark=0 use=1
```

At this connection there was only sent 1 packet which was the SYN, with NO REPLY!!!, but it says ESTABLISHED rather than SYN_SENT.

My prob is not the name, but the time out. This connection should timeout in 2 minutes, but it will timeout in more than a couple of hours!!!!

As you can imagine, this can eat up all my resources. Any ideas?

----------

## sque

After more reading on the conntrack system, I discovered that the 3rd entry is the time-out in seconds, so at the previous example

```
tcp      6 430878 ESTABLISHED src=192.168.0.50 dst=213.194.0.112 sport=63736 dport=80 packets=1 bytes=40 [UNREPLIED] src=213.194.0.112 dst=192.168.1.1 sport=80 dport=63736 packets=0 bytes=0 mark=0 use=1
```

It will timeout at 4,9 days!!!!!!!

I have checked and rechecked the kernel configuration, I have tryied many configuration combination but no hope!

----------

## nielchiano

I have no clue, but I'm also interested in the solution

----------

## sque

What was actually happening:

I was trying with nmap to scan random hosts for port 80. BUT the first packet of nmap was not SYN (as I thought), it was an ACK!

I dont know why nmap is doing this or why the connection tracking system takes it as an ESTABLISHED connection but its not SYN_SENT for sure.

The prob now is that I know a way to flood the conntrack with a simple nmap command, if an expert knows something more about this, plz reply here, but conntrack is NOT reporting wrongly as there was no SYN packet sent. sry:)

----------

## nielchiano

 *sque wrote:*   

> What was actually happening:
> 
> I was trying with nmap to scan random hosts for port 80. BUT the first packet of nmap was not SYN (as I thought), it was an ACK!

 

you can choose what scan to do with nmap... default is a SYN scan, but -sA does an ACK scan.

 *sque wrote:*   

> I dont know why nmap is doing this or why the connection tracking system takes it as an ESTABLISHED connection but its not SYN_SENT for sure.

 

why nmap does it, I don't know either.

but conntrack's behaviour is understandable: it asumes that the connection was already there before he was there, and thus asumes ESTABLISHED. I don't know if this is a good or bad thing... On one hand it's good, since it allows you to bring conntrack up without disturbing all connections

on the other hand, it is kind of a tunnel through your firewall...

 *Quote:*   

> The prob now is that I know a way to flood the conntrack with a simple nmap command, if an expert knows something more about this, plz reply here, but conntrack is NOT reporting wrongly as there was no SYN packet sent. sry:)

 

hmm... I'll folow this. Maybe report to the kernel mailinglist?

----------

## sque

From the Iptables Tutorial 1.2.0

---------------------------------------------------------------------------------------------

As you have seen, packets may take on several different states within the kernel itself, depending on what protocol we are talking about. However, outside the kernel, we only have the 4 states as described previously. These states can mainly be used in conjunction with the state match which will then be able to match packets based on their current connection tracking state. The valid states are NEW, ESTABLISHED, RELATED and INVALID. The following table will briefly explain each possible state.

Table 7-1. User-land states

State	Explanation

NEW   The NEW state tells us that the packet is the first packet that we see.

          This means that the first packet that the conntrack module sees,

          within a specific connection, will be matched. For example, if we see a SYN 

          packet and it is the first packet in a connection that we see, it will match. 

However, the packet may as well not be a SYN packet and still be

          considered NEW. This may lead to certain problems in some instances,

          but it may also be extremely helpful when we need to pick up lost

          connections from other firewalls, or when a connection has already timed

          out, but in reality is not closed.

ESTABLISHED The ESTABLISHED state has seen traffic in both directions and

          will then continuously match those packets. ESTABLISHED connections are 

          fairly easy to understand. The only requirement to get into an ESTABLISHED state is

          that one host sends a packet, and that it later on gets a reply from the other host.

          The NEW state will upon receipt of the reply packet to or through the firewall change to

          the ESTABLISHED state. ICMP reply messages can also be considered as ESTABLISHED,

          if we created a packet that in turn generated the reply ICMP message.

-------------------------------------------------------------------------------------------------

I copied that part of tutorial, because it claryfies that a connection where there is only one-way traffic must be considered as NEW regardeless the type of traffic. I am lost! For me it looks like a bug in connection tracking system, so I removed the [NO ERROR] tag from the thread title.

----------

## mwhitlock

 *sque wrote:*   

> I copied that part of tutorial, because it claryfies that a connection where there is only one-way traffic must be considered as NEW regardeless the type of traffic. I am lost! For me it looks like a bug in connection tracking system, so I removed the [NO ERROR] tag from the thread title.

 

sque,

I found this forum thread by a Google search because I too was seeing tons of ESTABLISHED [UNREPLIED] entries in my router's conntrack table.  It took some research, but I found out what causes that and how to stop it.

When conntrack sees a TCP packet that doesn't match any existing conntrack entry (i.e., the conntrack is in pseudo-state TCP_CONNTRACK_NONE):

If the packet's index is TCP_SYN_SET (i.e., only the SYN flag is set), a new conntrack entry is created and set to the TCP_CONNTRACK_SYN_SENT state.

If the packet's index is TCP_SYNACK_SET, the packet is ignored, and no new conntrack entry is created. This should only happen when conntrack is brought up in the middle of a TCP 3-way handshake. Ignoring the packet simply forces the client to resend the initial SYN. No harm, no foul.

Here's the kicker: if the packet's index is TCP_ACK_SET, a new conntrack entry is created and set to the TCP_CONNTRACK_ESTABLISHED state. The intent is to allow conntrack to pick up connections that were already established prior to conntrack coming up.

Otherwise, the packet is ignored.There are two ways to prevent your conntrack table from filling up with 5-day entries that are ESTABLISHED but [UNREPLIED]:

Set a netfilter rule in the FORWARD chain of the filter table that REJECTs any TCP packet that is in the NEW conntrack state but does not have the SYN flag set. This still allows an ESTABLISHED conntrack entry to be set up for the connection but the REJECT netfilter target will cause the router to reply with an RST packet, which will immediately put the conntrack entry into the CLOSE state, which has a default timeout of 10 seconds. You would also want to put a REJECT rule in the INPUT chain of the filter table, if you would otherwise DROP the packet.

If you're running a recent kernel, you can set the net.ipv4.netfilter.ip_conntrack_tcp_loose sysctl to 0. This will cause conntrack to ignore TCP_ACK_SET packets for conntracks in the TCP_CONNTRACK_NONE state. Thus, no conntrack entry is ever created for them. This is the solution I have chosen to employ.Here's an excerpt from the Iptables tutorial 1.2.0: *Quote:*   

> ...even a packet with no bit set or an ACK flag, will count as NEW. This can be used for redundant firewalling and so on, but it is generally extremely bad on your home network, where you only have a single firewall.

 That text is actually incorrect about packets with no flag set. If you look in the kernel source net/netfilter/nf_conntrack_proto_tcp.c, you will see that the next state for an ORIGINAL packet with an index of TCP_NONE_SET in a conntrack in the TCP_CONNTRACK_NONE state is sIV, which is the code for invalid. Only an ORIGINAL packet with an index of TCP_ACK_SET in a conntrack in the TCP_CONNTRACK_NONE state will cause a new ESTABLISHED conntrack entry to be opened.

It's probably worth mentioning that the thousands of ESTABLISHED [UNREPLIED] entries actually aren't harmful, even if they sit around for five days.  If conntrack runs out of slots in the conntrack table, it'll pick a non-ASSURED entry (hopefully the one with the soonest timeout, but I bet it doesn't) and just overwrite it.  Having a bunch of junk entries in the conntrack table probably does put more load on the system than necessary, though.

Hope this was helpful!

----------

