NetBSD Problem Report #39520

From www@NetBSD.org  Thu Sep 11 17:06:25 2008
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 6248A63B92A
	for <gnats-bugs@gnats.netbsd.org>; Thu, 11 Sep 2008 17:06:25 +0000 (UTC)
Message-Id: <20080911170624.DA94B63B853@narn.NetBSD.org>
Date: Thu, 11 Sep 2008 17:06:24 +0000 (UTC)
From: peter@boku.net
Reply-To: peter@boku.net
To: gnats-bugs@NetBSD.org
Subject: IPNAT fails to consistently handle FTP sessions
X-Send-Pr-Version: www-1.0

>Number:         39520
>Category:       bin
>Synopsis:       IPNAT fails to consistently handle FTP sessions
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    ipf-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 11 17:10:00 +0000 2008
>Last-Modified:  Thu Jan 01 04:13:24 +0000 2009
>Originator:     Peter Eisch
>Release:        4.0.0_PATCH
>Organization:
>Environment:
NetBSD adder 4.0.0_PATCH NetBSD 4.0.0_PATCH (PETER-FW) #11: Mon May 26 18:12:05 CDT 2008  peter@buster:/builds/netbsd-4-0/i386/obj/builds/netbsd-4-0/src/sys/arch/i386/compile/PETER-FW i386

>Description:
Using rules:

map vlan150 from local/24 to remote/32 -> vlan150/32 proxy port ftp ftp/tcp
map vlan150 from local/24 to remote/32 -> vlan150/32 portmap tcp/udp 40000:60000
map vlan150 from local/24 to remote/32 -> vlan150/32

Where local is the local net, remote is the remote system and 'vlan150/32' is the IP address on vlan150.

(I can email specific traces and config, but it would be wrong to put the addresses in the public record.)

FTP sessions will occasionally fail when going through this interface.  The problem will be in the PORT command where it still has the local IP address instead of it being NAT'd to vlan150/32's address.

By occasionally I mean that it may work for a few sessions but inevitably it will fail all from the same host.  

I modified the rules to replace local/24 with the specific host, but it would still fail.
>How-To-Repeat:
Configure an overload NAT and FTP through it.

My kernel config includes:

include "arch/i386/conf/GENERIC.MP"
ipmi0          at mainbus?
options IPSTATE_SIZE=92111
options IPSTATE_MAX=64433
options NAT_SIZE=2047
options RDR_SIZE=2047
options HOSTMAP_SIZE=8191
options NAT_TABLE_MAX=180000
options NAT_TABLE_SZ=16383
options         GATEWAY
options         BRIDGE_IPF
...


>Fix:
none, yet

>Release-Note:

>Audit-Trail:
From: Peter Eisch <peter@boku.net>
To: <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: bin/39520: IPNAT fails to consistently handle FTP sessions
Date: Tue, 16 Sep 2008 13:07:22 -0500

 More information:

 FTP totally fails to connect to the server if the client is NAT'd and ToE
 functions are enabled on the interface doing NAT.


 +--------+    +-------+    +--------+
 | client |--->| nbrtr |--->| server |
 +--------+    +------NAT   +--------+

 With ToE enabled, the interface near the server sees the SYN-ACK from the
 server but immediately returns a RST.  Simply disabling ToE with -tcp4sum
 and no other changes the client connects and works with the server.

 I'm still working on more information for the initial report.  Changing ToE
 did not affect the sporadic nature of the problem.



From: Peter Eisch <peter@boku.net>
To: <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: bin/39520: IPNAT fails to consistently handle FTP sessions
Date: Tue, 16 Sep 2008 14:02:38 -0500

 Here is a trace of the offending packet.

 13:51:46.838452 IP (tos 0x0, ttl  63, id 36513, offset 0, flags [DF],
 length: 67) BB.BB.BBB.BBB.58359 > CCC.CCC.CC.C.21: P [tcp sum ok] 30:57(27)
 ack 120 win 5840
         0x0000:  4500 0043 8ea1 4000 3f06 9b94 205b f382  E..C..@.?....[..
         0x0010:  9d9a 6007 e3f7 0015 a702 697e 320e c650  ..`.......i~2..P
         0x0020:  5018 16d0 e2ce 0000 504f 5254 2032 3036  P.......PORT.AAA
         0x0030:  2c39 2c33 342c 3135 302c 3232 372c 3235  ,A,AA,AAA,227,25
         0x0040:  310d 0a                                  1..
 13:51:46.949262 IP (tos 0x0, ttl  57, id 7011, offset 0, flags [none],
 length: 66) CCC.CCC.CC.C.21 > BB.BB.BBB.BBB.58359: P [tcp sum ok]
 120:146(26) ack 57 win 11468
         0x0000:  4500 0042 1b63 0000 3906 54d4 9d9a 6007  E..B.c..9.T...`.
         0x0010:  205b f382 0015 e3f7 320e c650 a702 6999  .[......2..P..i.
         0x0020:  5018 2ccc 7a97 0000 3530 3020 496c 6c65  P.,.z...500.Ille
         0x0030:  6761 6c20 504f 5254 2043 6f6d 6d61 6e64  gal.PORT.Command
         0x0040:  0d0a                                     ..

 The NAT rules for this are:

 map vlan150 from AAA.A.AA.AAA/32 to CCC.CCC.CC.C/32 -> BB.BB.BBB.BBB/32
 proxy port ftp ftp/tcp
 map vlan150 from AAA.A.AA.AAA/32 to CCC.CCC.CC.C/32 -> BB.BB.BBB.BBB/32
 portmap tcp/udp 40000:60000
 map vlan150 from AAA.A.AA.AAA/32 to CCC.CCC.CC.C/32 -> BB.BB.BBB.BBB/32

 The topology for this is:

              (wm1)   (wm2)
 +--------+  vlan154-vlan150   +--------+
 | client |---->| nbrtr |----->| server |
 +--------+     +------NAT     +--------+

 Again, this problem only happens for one out of every 5-8 sessions.  The
 successful sessions correctly insert the BB.BB.BBB.BBB address in the PORT
 command.



From: Peter Eisch <peter@boku.net>
To: <gnats-bugs@NetBSD.org>,
	<gnats-admin@netbsd.org>,
	<netbsd-bugs@netbsd.org>
Cc: 
Subject: Re: bin/39520: IPNAT fails to consistently handle FTP sessions
Date: Tue, 16 Sep 2008 13:34:32 -0500

 The ToE testing above was on a bge interface.  I'm not able to repeat this
 on a wm interface.


From: Peter Eisch <peter@boku.net>
To: <gnats-bugs@NetBSD.org>,
	<gnats-admin@netbsd.org>,
	<netbsd-bugs@netbsd.org>
Cc: 
Subject: Re: bin/39520: IPNAT fails to consistently handle FTP sessions
Date: Mon, 29 Sep 2008 13:48:46 -0500

 It breaks on a wm interface as well.

 /etc/ipnat.conf:
 ...
 map wm2 10.1.100.0/24 -> 0/32 proxy port ftp ftp/tcp
 map wm2 10.1.100.0/24 -> 0/32 portmap tcp/udp 40000:60000
 map wm2 10.1.100.0/24 -> 0/32
 ...
 bimap wm2    10.1.100.80/32 -> 208.79.193.34/32
 ...

 Tcpdump on the device just adjacent the client:
 12:39:58.763181 IP (tos 0x0, ttl 128, id 7163, offset 0, flags [DF], length:
 64) 10.1.100.129.1305 > 206.9.34.88.21: P [tcp sum ok] 35:59(24) ack 78 win
 65458
         0x0000:  4500 0040 1bfb 4000 8006 7fd9 0a01 6481  E..@..@.......d.
         0x0010:  ce09 2258 0519 0015 ccd1 38be aefa 4d54  .."X......8...MT
         0x0020:  5018 ffb2 e5ba 0000 504f 5254 2031 302c  P.......PORT.10,
         0x0030:  312c 3130 302c 3132 392c 352c 3238 0d0a  1,100,129,5,28..


 Tcpdump on the ftp server:
 12:33:48.346118 IP (tos 0x0, ttl 120, id 7163, offset 0, flags [DF], proto:
 TCP (6), length: 64) 208.79.193.34.pe-mike > 206.9.34.88.ftp: P, cksum
 0xc2ca (correct), 35:59(24) ack 78 win 65458
     0x0000:  4500 0040 1bfb 4000 7806 64e9 d04f c122  E..@..@.x.d..O."
     0x0010:  ce09 2258 0519 0015 ccd1 38be aefa 4d54  .."X......8...MT
     0x0020:  5018 ffb2 c2ca 0000 504f 5254 2031 302c  P.......PORT.10,
     0x0030:  312c 3130 302c 3132 392c 352c 3238 0d0a  1,100,129,5,28..


 Of course, int the second trace (on the server) the ftp client IP address
 should be 208.79.193.34 and not 10.1.100.129.



Responsible-Changed-From-To: bin-bug-people->ipf-bug-people
Responsible-Changed-By: darrenr@NetBSD.org
Responsible-Changed-When: Thu, 01 Jan 2009 04:13:24 +0000
Responsible-Changed-Why:


>Unformatted:

Home	PR Database Search