pfSense

Please post packet traces on both sides of the connection.
And the 7 snapshot has another fix in that area so try with it too.

Running 2.0-BETA5 (i386)
built on Mon Jan 17 19:56:49 EST 2011 with NAT and 2 external interfaces. Port 21 forwarded to internal Ip.

Logon succesful, runing ok in active mode. When switching to passive mode i get a timeout.

Bug is stil there .....

same here.
internal passive ftp with any rules doesen't work either.

Running 2.0-BETA5 (i386)
builtonMon Jan 17 21:39:59 EST 2011

I can confirm this bug. The same appens here, passive FTP does not work (build of Jan 16 2011)

Can you be more specific if the rdr to internal server of passive ftp does not work or normal client behind nat passive ftp does not work?

Normal clients behind nat. The FTP server is behind a nat too (pfsense).

Clients can connect without any problem, but the "ls" times out.
Client are seing the correct pasv address/port modified by pfsense, but the connection is not possible.

my ftp server is located behind opt interface of pfsense (dmz)
the clients from LAN side cannot connect with passive ftp and the same behaviour when trying to connect from WAN side.

If I analyze the traces and telnet to the offered port from passive ftp quickly, I get the output of the list command. (which normally times out by any ftp tool)

Michael Heller wrote:

my ftp server is located behind opt interface of pfsense (dmz)
the clients from LAN side cannot connect with passive ftp and the same behaviour when trying to connect from WAN side.

If I analyze the traces and telnet to the offered port from passive ftp quickly, I get the output of the list command. (which normally times out by any ftp tool)

outgoing passive works seamless.

the last snapshot
built on Jan 18 04:33:29 EST

is working for me.

2.0-BETA5 (i386)
built on Tue Jan 18 03:34:33 EST 2011

confirmed.. FTP helper is working..

after some heavy tests I found out that there are a lot of connections droped by the default deny rule!
This finally delays the transfer for a long time. But succeed at the end.

block
Jan 18 21:27:39 OPT1 x.x.x.5:65003 x.x.x.10:42498 TCP:SA
block
Jan 18 21:27:38 OPT1 x.x.x1.5:65003 x.x.x.10:42498 TCP:SA
block
Jan 18 21:27:35 OPT1 x.x.x.5:65003 x.x.x.10:42498 TCP:SA
block
Jan 18 21:26:56 OPT1 x.x.x.5:65001 x.x.x.10:52724 TCP:SA
block
Jan 18 21:26:32 LAN x.x.x.5:65000 x.x.x.10:44968 TCP:SA
block
Jan 18 21:26:05 LAN x.x.x.5:65001 x.x.x.10:52724 TCP:SA

on the other hand I had a lot of problems to update this thread because of blocked traffic either!

block
Jan 18 21:55:47 LAN x.x.x.10:49375 62.2.27.17:80 TCP:FPA
block
Jan 18 21:55:19 LAN x.x.x.10:49375 62.2.27.17:80 TCP:FPA

Testing with a client behind pfsense using Tue Jan 18 03:34:33. FTP helper takes down box when re-initializing a previously opened connection.

http://forum.pfsense.org/index.php/topic,31983.msg167162.html#msg167162

Also only able to retrieve the directory listing on the second try.

Response: 200 Switching to Binary mode.
Command: PASV
Response: 227 Entering Passive Mode (204,152,184,73,163,175).
Command: LIST
Error: Connection timed out
Error: Failed to retrieve directory listing
Status: Resolving address of ftp.freebsd.org
...
Command: TYPE I
Response: 200 Switching to Binary mode.
Command: PASV
Response: 227 Entering Passive Mode (204,152,184,73,77,241).
Command: LIST
Response: 150 Here comes the directory listing.
Response: 226 Directory send OK.
Status: Directory listing successful

Same problems as I reported before using the i386 Wed Jan 19 11:47:04 build.

With testing tonight I was 3 for 3 on crashing the system. The number of FTP connection attempts required varies (3-10) but I can crash the machine every time.

was running the SMP kernel
loaded the developer's kernel -> solid, cannot duplicate the crashes

loaded the developer's kernel -> solid, cannot duplicate the crashes
Nope just takes more tries to bring it down.

Have backtrace if needed.

There were some changes to the patches this afternoon. Grab the next snap that comes out (it's almost done building now, or should be) and try it again there.

Updated to Fri Jan 21 06:52:27. Sorry, still no love. The number of tries before failure is inconsistent. After updating it crashed on the very first FTP connection attempt. Second time I loaded the dev kernel and really had to hammer it, 15-20 tries. Third time, less than 10.

All the boot and debugger output is logged. I can offer any data or configuration changes you need to help get this solved. Just ask.

yes, the same behaviour for me.
still getting a lot of timeout/reconnets.

on thre other hand it looks much better by ftping internally.

Looks like FTP is working better with build from Tue Jan 25 06:07:53. Did not get a chance to really hammer on it. The connection occasionally hangs on LIST but no lockups.

Really ? On my side, it's still the same.. can't perform "LIST" command from WAN...

Just committed the final fix which should fix the issues and prevent hangs.

Yeah, this looks pretty good!

thnx

With 2.0-BETA5 (amd64)built on Thu Feb 3 22:33:00 EST 2011, it's not resolved. The LIST command times out from FTP client on WAN...

No problems for the last several builds. Thank you!

Been running recent builds on i386 and
no problems so far.
Thank You for your Work.