FTP/auth problems (slooow links)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



	I wonder ... are the boxes inside purely WIN boxes?
	-- What sort of outside connection do you have?
	-- Do you have a rule forcing MTU size on the outside interface?

		-- I've found that some WIN installations for some
	reason dont do MTU discovery by default.... I've had to
	turn it on ... although I suspect that it was turned off by
	previous administrators...

	(just a similar, although odd situation I've run into in the 
past...)

	Alistair Tonner


On 2002.10.13 09:08 Svein E. Seldal wrote:
> Hi,
> 
> I have read about a couple of previous discussions on the issues of 
> using iptables together with FTP and acheiving only really *slow* 
> throughputs. All Q's that I've read concludes that the remedy is to 
> either passthough auth (ident) packets or to reject it.
> 
> I have a linux (2.4.18) running iptables. It is a router and FW, and 
> is NAT'ing the internal address range (192.168.0.x) to the external 
> range (1.2.3.x). ip_conntrack, ip_conntrack_ftp and ip_nat_ftp are 
> all loaded in the router. It is a 266 PII with 128Mb memory.
> 
> For any machine that are placed on the inside, there are two methods 
> of getting to another machine on the inside: either using the direct 
> internal address 192.168.0.x or by using the external address 
> 1.2.3.x. The net result is the same, but the latter is routed through 
> the router (and will always be accepted).
> 
> Now, the problem is this: I open two FTP connections from the client 
> machine 192.168.0.10 to a server, the first to 192.168.0.5 and the 
> other connection to 1.2.3.5. Again, this is the same machine, only 
> one of them is going via. the router while the other is not.
> 
> The connection going via. the router is slow, very slow. The problem 
> is that is does not matter if I DROP, REJECT or ACCEPT the auth 
> (ident) port. It still is as extremely slow -- direct connection 
> takes 20 mins, while the routed version takes 2-3 hours!!.
> 
> My hypothesis could be that the ip_nat_ftp module is causing the 
> considerable delay, since it must read all FTP data (I'm unsure about 
> FTP-data though). Another theory could be that the routing memory of 
> the iptables/kernel is too small. How can I increase it?
> 
> Any one else got any ideas? (I've got a lot of angry customers on my 
> back...)
> 
> 
> Thanks,
> Svein Seldal
> 
> 
> 




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux