find_appropriate_src() BUG also exist in 2.4.24

find_appropriate_src() BUG also exist in 2.4.24

[wanghtb]

Hi, all

Still consider  a simple SNAT, without CONFIG_IP_NF_NAT_LOCAL selected 

[ Client A ] -----> [ Box B ] ----> [ Server C ]
iptalbes -A POSTROUTING -t nat -p udp  -j SNAT --to-source B:2000-3000

when two udp connection built:
ct1: ORIG A.1---> C.1   REPLY  C.1 ---> B.2000
ct2: ORIG B.2000 ---> C.2 REPLY C.2 ---> B.2000

then the third will hang on the system

B.2000 ---> C.1


So, I think ip_nat_local_fn() should be called in any situation:-)

Re: find_appropriate_src() BUG also exist in 2.4.24

[KOVACS Krisztian]

  Hi,

On Thu, 2004-03-04 at 09:32, wanghtb@legend.com.cn wrote:
> Still consider  a simple SNAT, without CONFIG_IP_NF_NAT_LOCAL selected 
> 
> [ Client A ] -----> [ Box B ] ----> [ Server C ]
> iptalbes -A POSTROUTING -t nat -p udp  -j SNAT --to-source B:2000-3000
> 
> when two udp connection built:
> ct1: ORIG A.1---> C.1   REPLY  C.1 ---> B.2000
> ct2: ORIG B.2000 ---> C.2 REPLY C.2 ---> B.2000
> 
> then the third will hang on the system
> 
> B.2000 ---> C.1
> 
> 
> So, I think ip_nat_local_fn() should be called in any situation:-)

  Instead of calling ip_nat_local_fn() in any situation, I think that
the endless loop should be fixed in ip_nat_setup_info(). The problems
are caused by get_unique_tuple() always returning the same tuple, which
is already used by a confirmed connection, and ip_nat_setup_info()
calling get_unique_tuple() forever.

  In 2.6.3, this should be solved, since get_unique_tuple() will check
the tuple returned by find_appropriate_src() to make sure it's not yet
used. This check is missing from the Linux 2.4 branch.

  In addition, I still think that src_cmp() is mistaken, it passes
errorneous arguments (the original source of the connection instead of
the SNAT-ted source) to in_range().

  Also, see Rusty's patch in his reply to Karlis Peisenieks' mail:

http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/012388.html

It is especially interesting, since he proposes that the whole loop
should be removed from ip_nat_setup_info(), and that the check in
ip_conntrack_alter_reply() is not needed anyway.

  Harald, or someone in the core team, what is your opinion?

-- 
 Regards,
   Krisztian KOVACS

Re: find_appropriate_src() BUG also exist in 2.4.24

[zhi wang]

>Still consider  a simple SNAT, without CONFIG_IP_NF_NAT_LOCAL selected 
>
>[ Client A ] -----> [ Box B ] ----> [ Server C ]
>iptalbes -A POSTROUTING -t nat -p udp  -j SNAT --to-source B:2000-3000

>when two udp connection built:
>ct1: ORIG A.1---> C.1   REPLY  C.1 ---> B.2000
>ct2: ORIG B.2000 ---> C.2 REPLY C.2 ---> B.2000

>then the third will hang on the system

>B.2000 ---> C.1

After some email communication with wanght@legend, and cleared my own
misunderstander, I agree that this is a bug. The following steps can faithfully
hang the linux 2.4.24 machine.
     [1.1.1.2]<--->[1.1.1.1  2.2.2.1] <--->[2.2.2.2]
     iptalbes -A POSTROUTING -t nat -j SNAT --to-source 2.2.2.1:2000-3000

1. Deselect the CONFIG_IP_NF_NAT_LOCAL.
   set up the route:
   at [1.1.1.2]: ip route add 2.2.2.0/24 via 1.1.1.1
   at [2.2.2.2]: ip route add 1.1.1.0/24 via 2.2.2.1
   at [1.1.1.1]: echo 1 > /proc/sys/net/ipv4/ip_forward

2. at [2.2.2.2] execute:
   nc -l -p 1023
   nc -l -p 1024

3. at [1.1.1.2] execute:
   nc -n -p 1023 2.2.2.2 1023
   at [1.1.1.1], assume port 2000 is used. that is, there is a conntrack:
             {1.1.1.2:1023-->2.2.2.2:1023, 2.2.2.2:1023-->2.2.2.1:2000}

4. at [1.1.1.1] execute:
   nc -n -s 2.2.2.1 -p 2000 2.2.2.2 1024
   then another conntrack will be created:
             {2.2.2.1:2000-->2.2.2.2:1024,  2.2.2.2:1024-->2.2.2.1:2000}

5. at [1.1.1.1] again execute:
   nc -n -s 2.2.2.1 -p 2000 2.2.2.2 1023
   Then NF will try to create a conntrack with:
             {2.2.2.1:2000-->2.2.2.2:1023, 2.2.2.2:1023-->2.2.2.1:2000}
   This will trigger the dead loop.


Why CONFIG_IP_NF_NAT_LOCAL disabled:
   When CONFIG_IP_NF_NAT_LOCAL is enabled, a null binding will be allocated at
LOCAL_OUT hook. While a LOCAL_OUT hook is consided for DNAT, nat will not call
find_appropriate_src, and it will try to do implicit source NAT. So, the
conntrack will be change to something like {2.2.2.1:2000-->2.2.2.2:1023,
2.2.2.2:1023-->2.2.2.1:2001} before the POSTROUTING hook is called, dead loop
will NOT occur. I believe this DNAT identity is the power of
CONFIG_IP_NF_NAT_LOCAL. It covers this and the LIST_DELETE bug. Because it is
consided as DNAT, the PREROUTING hook will NOT call ip_nat_rule_find in
LIST_DELETE bug setup. 

Current 2.6 kernel has fixed this bug. It should be used in current 2.4 kernel
also.

Some thoughts:
The purpose of find_appropriate_src as stated by the comment in the source
code, "If this srcip/proto/src-proto-part is currently mapped,and that same
mapping gives a unique tuple within the given range, use that". I am just
wondering why we can't be the first to use that mapping, if it is valid within
the given range?


=====
--
Regards
Wang, zhi

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

Re: find_appropriate_src() BUG also exist in 2.4.24

[Martin Josefsson]

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

On Sat, 2004-04-03 at 04:01, zhi wang wrote:

> Current 2.6 kernel has fixed this bug. It should be used in current 2.4 kernel
> also.

The fix is included in 2.4-bk, it will be included in 2.4.26 when that
is released.

-- 
/Martin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: find_appropriate_src() BUG also exist in 2.4.24

[KOVACS Krisztian]

  Hi,

On Sat, Apr 03, 2004 at 11:47:37AM +0200, Martin Josefsson wrote:
> On Sat, 2004-04-03 at 04:01, zhi wang wrote:
> > Current 2.6 kernel has fixed this bug. It should be used in current 2.4 kernel
> > also.
> 
> The fix is included in 2.4-bk, it will be included in 2.4.26 when that
> is released.

  Martin, I think this is a different problem than the LIST_DELETE-related
bug fixed in -bk (and 2.6.5). Are you sure it is solved?

-- 
 Regards,
  Krisztian KOVACS

Re: find_appropriate_src() BUG also exist in 2.4.24

[Martin Josefsson]

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

On Sun, 2004-04-04 at 18:44, KOVACS Krisztian wrote:
>   Hi,
> 
> On Sat, Apr 03, 2004 at 11:47:37AM +0200, Martin Josefsson wrote:
> > On Sat, 2004-04-03 at 04:01, zhi wang wrote:
> > > Current 2.6 kernel has fixed this bug. It should be used in current 2.4 kernel
> > > also.
> > 
> > The fix is included in 2.4-bk, it will be included in 2.4.26 when that
> > is released.
> 
>   Martin, I think this is a different problem than the LIST_DELETE-related
> bug fixed in -bk (and 2.6.5). Are you sure it is solved?

No, I should learn to eat breakfast before replying to mail :(

Ignore my reply. Need to get a clue :)

-- 
/Martin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

re: find_appropriate_src() BUG also exist in 2.4.24

[Phil Oester]

I too am having lockups every few hours on a heavily used gateway.  

Back in September, Rusty offered this patch:

http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/012388.html

Which to this point is not in either 2.4 or 2.6, but looks as though
it may actually fix the endless loop we seem to be experiencing.

Alternatively, the following patch was merged in 2.6, but is not present
in 2.4.24 -- could this also help?

--- 1.34/net/ipv4/netfilter/ip_nat_core.c	Sun Apr  4 15:21:19 2004
+++ 1.35/net/ipv4/netfilter/ip_nat_core.c	Sun Apr  4 15:21:19 2004
@@ -421,7 +421,8 @@
 			*tuple = ((struct ip_conntrack_tuple)
 				  { *manip, orig_tuple->dst });
 			DEBUGP("get_unique_tuple: Found current src map\n");
-			return 1;
+			if (!ip_nat_used_tuple(tuple, conntrack))
+				return 1;
 		}
 	}


Any thoughts on either of the above would be appreciated.

Phil Oester

Re: find_appropriate_src() BUG also exist in 2.4.24

[zhi wang]

Yes, there are different. This bug is because get_unique_tuple blindly accepts
whatever find_appropriate_src returns in 2.4.x. While 2.6.5 has the return
tuple checked by ip_nat_used_tuple. You must have know this.:)

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

Re: find_appropriate_src() BUG also exist in 2.4.24

[KOVACS Krisztian]

  Hi,

On Mon, 2004-04-05 at 14:20, zhi wang wrote:
> Yes, there are different. This bug is because get_unique_tuple blindly accepts
> whatever find_appropriate_src returns in 2.4.x. While 2.6.5 has the return
> tuple checked by ip_nat_used_tuple. You must have know this.:)

  Indeed. This was the cause that the in_range() fix caused problems in
2.4, and had to be backed out.

  Furthermore, I think that find_appropriate_src() is completely useless
in its current form. Note thate src_cmp(), after checking that the
source is the same, passes the source in the original direction as the
manip-to-be-applied to in_range. However, in case of SNAT, this is the
unmodified, original source! I suspect that the destination address in
the reply direction should be used instead, since that value is the new
value applied by NAT on the matching connection. A more detailed
description of the probelem, though somewhat braindump-like, is
available at

http://lists.netfilter.org/pipermail/netfilter-devel/2004-March/014418.html

-- 
 Regards,
   Krisztian KOVACS

re: find_appropriate_src() BUG also exist in 2.4.24

[zhi wang]

> Which to this point is not in either 2.4 or 2.6, but looks as though
> it may actually fix the endless loop we seem to be experiencing.
> 
Yes, the patch should work. The problem here is that, although we are sure it
is buggy, the semantic of the find_appropriate_src isn't all that clear. 

Its purpose is ,as stated in the comment, that "if this
srcip/proto/src-proto-part is currently mapped,and that same mapping gives a
unique tuple within the given range, use that". This makes NAT a little
predicatable for some protocols. But I wonder 

1. why we should care about other sessions, or why we must test that
srcip/proto/src-proto-part is currently mapped if that same mapping gives a
unique tuple. 

2. From the comment's words "that same mapping", I agreed that with KOVACS that
maybe the destionation IP of reply tuple should be used.



__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/