Hello list, I''m using a simple shorewall setup, 2 interfaces/zones (internal/internet) and NAT with ftp_conntrack build into the kernel (no loadable modules support). I''m having problems using active FTP, some transfers go OK, but every now and then the server recieves a RETR filename on the internal interface but sends out TR filename, so the RE is removed from the request, which of course couses the remote server to deny the transfer. I''m using 2.6.11 with shorewall 2.4.2. Kind regards, Erik ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
Erik wrote:> Hello list, > > I''m using a simple shorewall setup, 2 interfaces/zones > (internal/internet) and NAT with ftp_conntrack build into the kernel (no > loadable modules support). > I''m having problems using active FTP, some transfers go OK, but every > now and then the server recieves a RETR filename on the internal > interface but sends out TR filename,By "server", I assume that you mean the system running Shorewall. If so, it is a "router/firewall", not a server -- the "server" is the remote system that your ftp clients are connecting to.> so the RE is removed from the > request, which of course couses the remote server to deny the transfer. > I''m using 2.6.11 with shorewall 2.4.2.Whatever problem you are seeing, it has nothing to do with Shorewall. It could be a bug in the ftp helpers in the kernel but it would be a very odd one since RETR isn''t one of the commands that the helpers even look for (they look for PORT and EPRT commands, and 227 (PASV) and 229 (EPSV) replies). FWIW, I monitor both the netfilter users and developers lists and I''ve not heard of a problem like this. Sorry that I can''t be more helpful, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> Erik wrote: > >>Hello list, >> >>I''m using a simple shorewall setup, 2 interfaces/zones >>(internal/internet) and NAT with ftp_conntrack build into the kernel (no >>loadable modules support). >>I''m having problems using active FTP, some transfers go OK, but every >>now and then the server recieves a RETR filename on the internal >>interface but sends out TR filename, > > > By "server", I assume that you mean the system running Shorewall. If so, > it is a "router/firewall", not a server -- the "server" is the remote > system that your ftp clients are connecting to. >Yes, I stand corrected. The firewall recieved RETR filename on the internal interfaces, does some magic and sends out TR filename to the FTP server the user is trying to use.> >>so the RE is removed from the >>request, which of course couses the remote server to deny the transfer. >>I''m using 2.6.11 with shorewall 2.4.2. > > > Whatever problem you are seeing, it has nothing to do with Shorewall. It > could be a bug in the ftp helpers in the kernel but it would be a very > odd one since RETR isn''t one of the commands that the helpers even look > for (they look for PORT and EPRT commands, and 227 (PASV) and 229 (EPSV) > replies). >In an ethereal trace i see some more strange things (tcp seq out of order etc) and i suspect the machine might be out of memory, i''ll try with some more memory (it''s a VM running shorewall using 2 bridged vlans with /30''s on them, one for LAN and one for WAN access).> FWIW, I monitor both the netfilter users and developers lists and I''ve > not heard of a problem like this. > > Sorry that I can''t be more helpful, > -Tom------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
Tom Eastep wrote:> > FWIW, I monitor both the netfilter users and developers lists and I''ve > not heard of a problem like this. >One problem that I *have* seen is commands/replies being split over two packets which could be mis-interpreted as what you are seeing (the "RE" is at the end of one packet and the "TR" at the beginning of the next). When this happens with one of the command/replies that the helpers look for, the helper will issue a message such as Apr 28 23:55:09 gateway kernel: conntrack_ftp: partial PORT 715014972+1 You might check your logs for those. There is no good solution for this problem when it occurs with outgoing FTP connections other than to try another FTP client, configure an FTP proxy (Squid) on the firewall or switch to passive mode. http://www.shorewall.net/FTP.html gives a solution for incoming connections (see example 4). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> Tom Eastep wrote: > >> FWIW, I monitor both the netfilter users and developers lists and I''ve >> not heard of a problem like this.Ok -- I had a few minutes and checked the Netfilter archives again. There were reports of FTP connection tracking corrupting FTP sessions and a patch was released. I recommend that you patch your kernel up to 2.6.11.9 and see if that doesn''t help. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Erik wrote:>> > In an ethereal trace i see some more strange things (tcp seq out of > order etc)The fix that I mentioned in my previous post dealt with the order in which helper modules were called and TCP sequence numbers were adjusted. See: http://lists.netfilter.org/pipermail/netfilter-devel/2005-May/019820.html -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> Erik wrote: > > >>In an ethereal trace i see some more strange things (tcp seq out of >>order etc) > > > The fix that I mentioned in my previous post dealt with the order in > which helper modules were called and TCP sequence numbers were adjusted. > > See: > http://lists.netfilter.org/pipermail/netfilter-devel/2005-May/019820.html > > -TomTom, Thanks for the pointer, i''ll try patching my Xen kernel with that patch and see if it works. Kind regards, Erik Versavel ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl