[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Why some NAT ftp proxying is failing (fwd)
From:       Darren Reed <darrenr () cyber ! com ! au>
Date:       1997-09-13 2:20:38
[Download RAW message or body]

In some mail I received from Jeremy Cooper, sie wrote
> From jeremy@pillbox.broder.com Sat Sep 13 12:02:29 1997
> Delivered-To: darrenr@netbsd.org
> Date: Fri, 12 Sep 1997 19:01:36 -0700 (PDT)
> From: Jeremy Cooper <jeremy@broder.com>
> To: darrenr@netbsd.org
> Subject: Why some NAT ftp proxying is failing
> Message-ID: <Pine.BSI.3.96.970912183042.19021J-100000@pillbox.broder.com>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> I went through the IPfilter archives and I noticed that some people were
> having trouble getting the FTP proxy to work.  (Actually, I haven't seen
> anyone report a _positive_ success.)  I myself am having problems and I've
> found the bug preventing it, but I'm not sure where it's originating.
> 
> I am using 3.2beta4 on FreeBSD-2.2.1 and using just one NAT rule:
> 
> map ep0 10.1.0.0/24 -> 10.1.2.0/29 proxy port ftp ftp/tcp
> 
> I have configured a Macintosh with EtherPeek, a very handy network
> debugging and sniffing app.  I placed this mac on the dirty (10.1.2.0)
> network and sniffed an FTP session through the NAT.  All goes well until
> the PORT command.  When IPNAT re-writes the PORT command inside the
> packet, the TCP checksum is not being recomputed properly.  I took a look
> at fil.c:fr_tcpsum() and it appears to be doing the right thing, so the
> problem is probably somewhere else.  I'll let you know if I find it, but
> in the mean time you can let everyone know why it doesn't work.
> 
> -J

[prev in list] [next in list] [prev in thread] [next in thread]