Understanding conntrack: Delete and manual readd of same entry possible?

Understanding conntrack: Delete and manual readd of same entry possible?

[Roman Fiedler]

Hi list,

The failure to conduct a simple test with conntrack makes me believe, 
that I misunderstood some part of the concept.

The testcase:

* Create one forwarded tcp connection via iptables-firewall and leave it 
open
* Delete the conntrack entry of this connection
* Readd the same conntrack entry with conntrack -I
* Verify, that old and new entry looked the same (conntrack -L)
* Send one more byte over the still open tcp connection

The expected result:
* TCP flow continues without creating a new conntrack entry, using the 
one added manually
* ACCEPT via ESTABLISHED rule because of valid conntrack entry

The actual result:
* Conntrack code seems to believe, that packets do not belong to 
conntrack entry
* Conntrack code does not create new conntrack entry
* Conntrack code cannot update conntrack-entry even when packet is accepted.

Can someone enlighten me, if manual entry creation is possible?

Thanks, Roman

Re: Understanding conntrack: Delete and manual readd of same entry possible?

[Pablo Neira Ayuso]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

Roman Fiedler wrote:
> Hi list,
> 
> The failure to conduct a simple test with conntrack makes me believe, 
> that I misunderstood some part of the concept.
> 
> The testcase:
> 
> * Create one forwarded tcp connection via iptables-firewall and leave it 
> open
> * Delete the conntrack entry of this connection
> * Readd the same conntrack entry with conntrack -I
> * Verify, that old and new entry looked the same (conntrack -L)
> * Send one more byte over the still open tcp connection
> 
> The expected result:
> * TCP flow continues without creating a new conntrack entry, using the 
> one added manually
> * ACCEPT via ESTABLISHED rule because of valid conntrack entry
> 
> The actual result:
> * Conntrack code seems to believe, that packets do not belong to 
> conntrack entry
> * Conntrack code does not create new conntrack entry
> * Conntrack code cannot update conntrack-entry even when packet is 
> accepted.
> 
> Can someone enlighten me, if manual entry creation is possible?

I seem to have overlooked this email, sorry. You need this patch in 
order to make it work, I'm going to apply it to git.netfilter.org now so 
it will be available in the next release.

[-- Attachment #2: fix-tcp-manually.patch --]
[-- Type: text/x-patch, Size: 1464 bytes --]

conntrack: fix manually created TCP entries with window tracking enabled

From: Pablo Neira Ayuso <pablo@netfilter.org>

With this patch, we allow to manually create TCP entries in the table.
Basically, we disable TCP window tracking for this entry to avoid
problems.

Reported-by: Roman Fiedler <roman.fiedler@ait.ac.at>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 extensions/libct_proto_tcp.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/extensions/libct_proto_tcp.c b/extensions/libct_proto_tcp.c
index ac54ac7..f229aea 100644
--- a/extensions/libct_proto_tcp.c
+++ b/extensions/libct_proto_tcp.c
@@ -202,6 +202,22 @@ static void final_check(unsigned int flags,
 			break;
 		}
 	}
+	/* Disable TCP window tracking for manually created TCP entries,
+	 * otherwise this will not work.
+	 */
+	uint8_t tcp_flags = IP_CT_TCP_FLAG_BE_LIBERAL |
+			    IP_CT_TCP_FLAG_SACK_PERM;
+
+	/* This allows to reopen a new connection directly from TIME-WAIT
+	 * as RFC 1122 states. See nf_conntrack_proto_tcp.c for more info.
+	 */
+	if (nfct_get_attr_u8(ct, ATTR_TCP_STATE) >= TCP_CONNTRACK_TIME_WAIT)
+		tcp_flags |= IP_CT_TCP_FLAG_CLOSE_INIT;
+
+	nfct_set_attr_u8(ct, ATTR_TCP_FLAGS_ORIG, tcp_flags);
+	nfct_set_attr_u8(ct, ATTR_TCP_MASK_ORIG, tcp_flags);
+	nfct_set_attr_u8(ct, ATTR_TCP_FLAGS_REPL, tcp_flags);
+	nfct_set_attr_u8(ct, ATTR_TCP_MASK_REPL, tcp_flags);
 }
 
 static struct ctproto_handler tcp = {

Re: Understanding conntrack: Delete and manual readd of same entry possible?

[Roman Fiedler]

Pablo Neira Ayuso wrote:
> Roman Fiedler wrote:
>> Hi list,
>>
>> The failure to conduct a simple test with conntrack makes me believe,
>> that I misunderstood some part of the concept.
>>
>> The testcase ....
>
> I seem to have overlooked this email, sorry. You need this patch in
> order to make it work, I'm going to apply it to git.netfilter.org now so
> it will be available in the next release.

Thanks for the patch. When I've played with the same problem at home I've
guessed that it is something with sequence numbers and that setting tcp-liberal
in a netlink test application is a workaround for the DROP. But I did not
bring it to that point that I could create a clean patch because there were
still some loose ends. Perhaps someone could help me to fix some of these:

a) When conntrackd inserts the entries, does it set the liberal also? If yes,
is it correct, that a failover via conntrackd would disable sequence number
tracking for all existing entries?

b) Does the netlink api support sequence number parameters? If not, should it?

c) If the sequence numbers are not set by the conntrack utility, where do the
values in the kernel space come from? Are they all 0 or is it uninitialized
memory from user or kernel space?

Re: Understanding conntrack: Delete and manual readd of same entry possible?

[Pablo Neira Ayuso]

Roman Fiedler wrote:
> Thanks for the patch. When I've played with the same problem at home I've
> guessed that it is something with sequence numbers and that setting 
> tcp-liberal
> in a netlink test application is a workaround for the DROP. But I did not
> bring it to that point that I could create a clean patch because there were
> still some loose ends. Perhaps someone could help me to fix some of these:
> 
> a) When conntrackd inserts the entries, does it set the liberal also? If 
> yes,
> is it correct, that a failover via conntrackd would disable sequence number
> tracking for all existing entries?

Yes, this is the way it works by now, but it would be easy to make a 
patch not to disable it. I'm going to prepare one now that 
conntrack-tools 0.9.14 is out. I'll let you know, you may want to help 
me doing some testing.

> b) Does the netlink api support sequence number parameters? If not, 
> should it?

IIRC the kernel already supports it, but user-space support for 
libnetfilter_conntrack and conntrackd is still missing.

> c) If the sequence numbers are not set by the conntrack utility, where 
> do the
> values in the kernel space come from? Are they all 0 or is it uninitialized
> memory from user or kernel space?

Not sure what you mean. Currently, we are setting the 
IP_CT_TCP_FLAG_BE_LIBERAL flag so window tracking is disabled for 
entries created via ctnetlink.

I'm going to look into this so we may have it for the next 
conntrack-tools release.

Re: Understanding conntrack: Delete and manual readd of same entry possible?

[Pablo Neira Ayuso]

Pablo Neira Ayuso wrote:
> Roman Fiedler wrote:
>> Thanks for the patch. When I've played with the same problem at home I've
>> guessed that it is something with sequence numbers and that setting 
>> tcp-liberal
>> in a netlink test application is a workaround for the DROP. But I did not
>> bring it to that point that I could create a clean patch because there 
>> were
>> still some loose ends. Perhaps someone could help me to fix some of 
>> these:
>>
>> a) When conntrackd inserts the entries, does it set the liberal also? 
>> If yes,
>> is it correct, that a failover via conntrackd would disable sequence 
>> number
>> tracking for all existing entries?
> 
> Yes, this is the way it works by now, but it would be easy to make a 
> patch not to disable it. I'm going to prepare one now that 
> conntrack-tools 0.9.14 is out. I'll let you know, you may want to help 
> me doing some testing.

BTW, conntrackd does not set to liberal other entries that already 
exists in the kernel (in case that you have some active-active setup). 
So only the injected entries are set to liberal by now. I think that 
this replies to the second part of your question, right?