>Number:         14579
>Category:       kern
>Synopsis:       ftp sessions with ipnat fail when doing mkdir
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 13 13:38:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Emmanuel Dreyfus
>Release:        NetBSD-1.5.2/i386
>Organization:
The NetBSD Project
>Environment:
>Description:
I'm facing a strange bug with an average ipnat setup (about 40 machines
behind the NAT): from any machine behind the NAT, I can launch a FTP
session, I can do list directories or download (all in passive mode),
but when I try to create a directory, the connection is closed or it
times out (depends on the filter rules)

By sniffing packets before and after the NAT, it seems to me that the
port used for mapping the connection changes when I create the
directory.

Here are the packet dumps by snort. 
192.168.3.41 is the client address
y.y.y.y is the external address of the NAT
x.x.x.x is the server address.

Dump before the NAT (actually on the NAT internal interface)
http://hcpnet.free.fr/client

Dump after the NAT (actually on the server)
http://hcpnet.free.fr/server

Looking at both dumps, it seems to me that the problem appears between
the third and the second packet, starting at the end: the port number on
the external address of the NAT changes, whereas it's obviously the same
connection.

I reproduced the problem both on NetBSD-1.5.2 and NetBSD-current. 
Removing filter rules does nothing to the problem.
>How-To-Repeat:
Hard. I use an automated NetBSD installation CDs to make NATs. On the
same box, I repeated the problem when I reinstalled. But I have another 
machine on an other network, installed with the same CD, and the 
problem does not exist on this machine. I was not able to precisely 
understand what was causing the bug... But I have a fix (see 
next section)
>Fix:
The solution was to upgrade IPFilter to 3.4.21 (while keeping a 1.5.2
kernel). There is a strange bug at startup: ipnat loads its rules, 
ipnat -l reports they are loaded, but ipnat is not really started: no
NAT, no rdr. I have to do this in rc.local to get ipnat really started: 
ipf -D; ipf -D; sleep 2; ipf -E; ipnat -FC -f /etc/ipnat.conf

Apart from this strange problem, things are fine, and the ftp problem
is fixed.
>Release-Note:
>Audit-Trail:
>Unformatted: