Hello,

I've investigated this problem more closely, and it seems to me that the 
problem is *not* related to FTP only, but the general time-delay on 
connection openings. The reason this is apparent on FTP, is when 
transferring 1000 small files, 1000 connections has to be opened, thus 
the delay will be significant and noticeable.

A couple of persons have asked be about /etc/resolv.conf and how DNS 
resolver is setup. I thought the incoming/outgoing packets never where 
resolved with DNS due to the significant delay. Is this true?

Antony Stone wrote:
> Without seeing your ruleset I cannot be certain, but I would not expect the 
> latter situation to work properly, for reasons explained below...

Here you go...

> I think you need to think about the route of packets and their replies.
> 
> Consider machine 192.168.0.10 connecting to 192.168.0.5.   Both are on the 
> same subnet, therefore client sends packets to server and server sends 
> packets to client - all works well.
> 
> Now consider 192.168.0.10 sending packets to 1.2.3.5.   These go via your 
> router, which translates 1.2.3.5 to 192.168.0.5, and returns them to the 
> subnet where they originated.   Now where is the server going to reply to ?   
> 192.168.0.10, because that is the address which sent the original packet...
> 
> Therefore 192.168.0.10 sends a packet to 1.2.3.5 and gets a reply from 
> 192.168.0.5 (the reply goes directly from server to client, not through the 
> NAT router, because both addresses are on the same subnet), therefore 
> 192.168.0.10 gets confused and unhappy.

Maby I have been thinking all wrong all the time, but I'm not quite sure 
this statement is quite true... Please correct me if I'm wrong.!

192.168.0.10 is sending packets to 1.2.3.5. The router received it and 
does a DNAT, translating destination 1.2.3.5 to 192.168.0.5. Then it 
performs the FW-stuff. Then it is going to be sent out on the interface, 
it will be SNAT'ed, where the source address, 192.168.0.10 will be 
changed to 1.2.3.10. Hence, the packet the server receives is to 
192.168.0.5 and from 1.2.3.10. And this works reversely for packets 
being sent back to the client.

Regardless of the discussion above is correct or not, the same phenomen 
is observerved on connections from internet to lan and on lan to internet.

BTW! Is there a benefit of increasing the routing memory in the kernel? 
(Regardless of the problems above.) This is a dedicated router, so IMHO 
should use as much memory for routing as possible, right?


Thanks for all the help I get,
(If I cant resolve this within a sensible amount of time, my boss will 
buy a Cisco router...)

Svein