> > we have a ftp connection which passes through two routers which have a
> > IPSEC tunnel in between. Both routers have nat and conntrack modules
> > compiled into the kernel but there are no rules at all.
> 
> You mean there are also no filter rules? Good. That excludes much.

No filter rules and no nat rules.

 
> > [a simple ftp connection which goes through the IPSEC tunnel.]
 
> > Now, the connection is established succesfully but "ls" ftp command
> > fails. We are using newnat on a 2.4.18 kernel. With old nat on 2.4.18 
> > kernel this problem did not occured, but I am not sure if it is a newnat
> > bug or an IPSEC bug.
> 
> Great! Can you alternately try with oldnat and newnat? If you use tcpdump
> or ethereal during such tests, you may be able to discern whether the
> incoming or outgoing path is dropping first. Use oldnat as a baseline
> "what should happen" packet dump, and compare a newnat trace to that
> to see where it starts differing. You can do this on both routers
> and/or external vs. internal router interface to provide further info.
>
we did. 
 
> Could you possibly try newnat without ipsec, e.g. with a crossover cable
> between the routers?

we tried. :-) it works. :-( it also works if we compile the kernel without
the ip_tables, ip_nat_ftp and ip_conntrack_ftp modules.

> I haven't, personally; just trying to ask hopefully pertinent questions.
> Hope they are a bit helpful.
thanks a lot for your answers.

I guess the problem is somewhere in the ipsec module. It has problems with
packets fragmentation. Or at least this is what I can see watching the
traffic with ethereal. 


For the following scenario:

  FTP            Router     IPSEC tunnel      Router            FTP  
 Client ---------  R1  =======================  R2  ---------- Server


In order to execute the "ls" command the FTP client opens a data
connection through which the answer from the ftp server will come. This
connection is opened succesfully. All the control part works fine.

The problem is that the first data packet coming from the server gets lost
at R1 which sends an ICMP packet back to the TCP server which is
closing the data connection. The ICMP packet is a "Destination
unreachable; Fragmentation needed" packet. 

Since the packet is send form the IPSEC module I quess that the error
might be there. 

I'm still digging. 

Thanks Patrick.

best regards,
        Felix





Reply via email to