Re: [netfilter-core] iptables/conntrack in enterprise environment.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 30 May 2003 03:42 pm, Harald Welte wrote:
> > If I then telnet to 10.0.0.1 on port 5050, the connection is immediate,
> > and my application receives a new connection on port 5050.  If, however,
> > I telnet to 10.0.0.1 on port 5150, there is a small (but noticable) delay
> > between when the telnet session shows the connection as established, and
> > when the application receives the connection (on a random port between
> > 5000 and 5100 inclusive).
>
> This is _definitely_ not a netfilter issue then.  We are not doing
> transparent proxying but nat.  netfilter/iptables _never_ accept
> connections on their own.  So you open a connection:
Maybe not, but thats the behavior I'm seeing.  But this doesnt bother me so 
much as it takes a LOT longer for a connection to be established when 
connecing to a port outside the range, than to one inside the range.


> 1. telnet 10.0.0.1 5150
> 2. syn packet is sent by telnet
> 3. syn packet is DNAT'ed by netfilter
> 4. syn packet arrives at server application
> 5. syn/ack packet is sent by server application
> 6. syn/ack packet is SNAT'ed by netfilter
> 7. syn/ack packet is received by telnet
>  [further handshake goes on]
> x. telnet application prints 'Connection established' (connect(2) call
>    returns)
>
> This is a fundamental tcp/ip operation, and it can certainly by no way
> be anything that netfilter does, that would introduce a behaviour like
>
> 1. telnet 10.0.01 5150
> 2. telnet shows 'connection established'
> 3. connection 'arrives' at server
>
> [which is what you have been describing, If I understood you correctly].
I realise this is supposed to happen, however again, its not what I'm 
observing, though its only noticable under high loads, so maybe its taking a 
long time to get the initial SYN and ACK to the server from telnet (which 
would account for both the delay before connection is established by telnet 
(delay for SYN/ACK to get back from server), and the delay between this and 
the server showing the connection established (which only happens after it 
gets the ACK).

OK, so with this information, its taking a LONG time to get the SYN and ACK to 
the server when I'm connecting to a port outside the range I'm listening on 
with the application, causing the appearance of the port being connected by 
telnet a long time before the server shows it being established.  In any 
case, this doesnt change the problem.  This delay does *NOT* exist when 
connecting to a port that is in the listening range (remember that all 
connections being discussed here are going to systems BEHIND the router box).

I did some kernel diving, I've iscolated the place where the behavior 
differentiates between a connection 'in' and 'out' of the port range, at this 
if statement in get_unique_tuple (ip_nat_core.c):
               if ((!(rptr->flags & IP_NAT_RANGE_PROTO_SPECIFIED)
                     || proto->in_range(tuple, HOOK2MANIP(hooknum),
                                        &rptr->min, &rptr->max))
                    && !ip_nat_used_tuple(tuple, conntrack)) {

Obviously, anything connecting to a port outside this range will fail the 
above if.  If this fails, it will lead us to do this (one way or another):
                       if (proto->unique_tuple(tuple, rptr,
                                                HOOK2MANIP(hooknum),
                                                conntrack)) {

The unique_tuple function is where the delay is.  In this case, its a TCP 
connection, which translates to tcp_unique_tuple (ip_nat_proto_tcp.c), which 
after determining the port range, does the following:
        for (i = 0; i < range_size; i++, port++) {
                *portptr = htons(min + port % range_size);
                if (!ip_nat_used_tuple(tuple, conntrack)) {
                        return 1;
                }
        }

Now I'm assuming it will use this:
                min = ntohs(range->min.tcp.port);
                range_size = ntohs(range->max.tcp.port) - min + 1;
rather than this:
                        min = 1024;
                        range_size = 65535 - 1024 + 1;
for my port range, since I specified a local port range, however either way, 
the range is about 100 ports.  Which means the above nat used lookup happens 
100 times (as opposed to once for when the port is inside the range).  And 
since ip_nat_used_tuple (ip_nat_core.c) calls ip_conntrack_tuple_taken 
(ip_conntrack_core.c), which subsequently locks/unlocks the entire conntrack 
table, and calls __ip_conntrack_find (which is a list lookup!), the above for 
loop is a very intensive process.

Now, after all that.  A few questions arise:
1) Is there a way the above for loop could lock the conntrack table 
beforehand, do the searches (not locked) and unlock afterwards.  This is 
probably the biggest thing consuming all the speed, constant 
locking/unlocking, especially when there are many new socket connections 
coming in every second.

2) Is there a way the above for loop could use a random 'start' place, search 
through to the end, and then start at the beginning, until it ends up back at 
the same place it started from, which would avoid it constantly treading the 
same ground (if the last entry used 1, its pretty assured 1 is still going to 
be in use when you get the next entry, so you could either skip directly to 
2, or randomly choose a new position to start at). (ie. something like:
	int port, start_port = (rand() % range) + min_port);
	for (port=start_port; port<min_port + range; port++)
		{ if (!used) { return 1; } }
	if (port == min_port + range)
		for (port = min_port; port < start_port; port++)
			{ if (!used) { return 1; } }
	return 0;
).  Obviously, the kernel's rand would need to be used, etc.

3) Why does it need to do the unique check in the first place (for DNAT and 
REDIRECT), since this code should only be triggered on a new connection, and 
if I have 2 new connections from the same source, to the same destination and 
the same destination (nat'd) port, who cares?  The destination port has to be 
listening for it anyway, and theres nothing stopping it accepting 2 
connections from the same source to the same local port (the source port will 
always be different).  I'm assuming the 'resend' checks are done before this 
point anyway (using the ORIGINAL destination ip/port, not the nat'd one) in 
the system's TCP stack.

Anyway, if I'm way off base here, let me know, but I'm just trying to figure 
out why there is a difference between connecting to a port inside, and a port 
outside the range I'm listening to on the router.  Its not a small difference 
(time wise) either.

And re: your other email:
1) I know SNATs is not a TCP state, the data was copied from a file I generate 
every 5 minutes gathering this data, and that was the line above what I ment 
to copy.
2) When I said 'without state', I mean UDP connections, since they don't have 
TCP state information.

- -- 
PreZ
Systems Administrator
Shadow Realm

PGP FingerPrint: B3 0C F3 32 DE 5A 7D 90  26 F6 FA 38 CC 0A 2D D8
Finger prez@xxxxxxxxxxxxx for full PGP public key.

Shadow Realm, a hobbyist ISP supplying real internet services.
http://www.srealm.net.au
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+1/2LKFp14D8AGEQRAhvtAKCGLi7R2DhiAGbluUhSxRBcuViR9wCfdU4J
+ycatke7LILAa+xRYDPOb7c=
=Ngon
-----END PGP SIGNATURE-----




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux