RC3 : Passive FTP disconnects after 127 "PASV" commands !

rancor

All those packets are blocked by the default deny rule apparently :

The rule that triggered this action is:

@1 scrub in on em1 all fragment reassemble
@1 block drop in log all label "Default deny rule"

Notre also that I have a lot of those logs. I am not worried because I have read this article, but is it normal that all packets have to be reassembled to be passed on to the firewall ?

Yes, if one of the routers along the path to destination requires smaller packet size when the originating MTU the firewall needs to reassemble the packets. Often seen on tunnelled connection like GRE or VPN.

thewild

OK. That seems to be the case for most if not all connections, but that is not connected to my problem anyway.

Now, I am not sure that what I see in the firewall log is related to the passive connection problem…

thewild

Sorry for "upping" this thread, but this problem is quite problematic for us.

Is there something else I should check or some parameter I could try to change ?

Thanks a lot for your help !

pinoyboy

1 - Are you using port redirect or static mapping for ip of FTP?
2 - Attached small screenshot of the WAN / LAN rule pertaining to FTP only.
3 - Have you set static port range for PASSIVE FTP on FTP Server itself, if so what are exact numbers / ranges?

thewild

Thanks for your answer pinoyboy !

@pinoyboy:

1 - Are you using port redirect or static mapping for ip of FTP?

I don't understand your question. I have a simple NAT rule to forward port 21 to the private address of the FTP server, the passive part is handled by the FTP Proxy I guess ?

2 - Attached small screenshot of the WAN / LAN rule pertaining to FTP only.

As I said, very basic rule.
http://i54.tinypic.com/ih3x2p.png

3 - Have you set static port range for PASSIVE FTP on FTP Server itself, if so what are exact numbers / ranges?

No, I tried but it did not seem to help. I think I tried with a 1000 port range, from 21000 to 21999.

thewild

Back on the case. I upgraded to the latest RC3 (25th July) and did some more testing.

It appears that the connection error comes exactly every 127 PASV commands (the 128th fails).
I changed the subject of my post because I had written every 100-200 PORT command.

That is of course not a coincidence.

My client FTP software does a directory tree scanning, and it issues a "PASV" command for every directory in the tree (afterwards it issues an MLSD command).
Since the command is very fast to run, my client issues a lot of "PASV" commands in a very short time.

The the sequence is :
-> PASV
<- 227 entering passive mode
-> MLSD
<- directory information
-> PASV

…. 127 times

-> PASV
<- 227 entering passive mode
-> MLSD
Error, server closed connection.

I hope this helps to understand where the problem is ?

danswartz

Boy, that sounds like someone is using a signed byte where they shouldn't be…

thewild

@danswartz:

Boy, that sounds like someone is using a signed byte where they shouldn't be…

I guess I should submit this issue in redmine then ?

eri--

Please try a snapshot from tomorrow and check if is ok.

thewild

@ermal:

Please try a snapshot from tomorrow and check if is ok.

OK, I'll try it ASAP.
Server is in production, so I have to do this outside of business hours.

thewild

@ermal:

Please try a snapshot from tomorrow and check if is ok.

Just tried with the latest snapshot, and it works great !
~28.000 folders scanned by the FTP client in less than 10 minutes, no deconnection !
That's perfect, thanks a lot !