ftp client passive mode

sasa1

@johnpoz said in ftp client passive mode:

Well sniff it on pfsense, diagnostic packet capture..
On the lan side sniff for the dest IP so you can see all traffic going there, then on the wan side of pfsense sniff on the dest IP..
Sniff on the client other than for trying to figure out why its not resolving is going to be pretty useless, unless its local firewall blocking the return traffic on active.. Which sure it could be..
But your going to want to sniff both lan and wan side on pfsense to validate the ftp package is changing the IP of the client for the active to work.

I captured the packages and this is the result:

13:05:05.516740 IP 93.57.xxx.xxx.24479 > 90.130.70.73.21: tcp 0
13:05:05.561254 IP 90.130.70.73.21 > 93.57.xxx.xxx.24479: tcp 0
13:05:05.561304 IP 93.57.xxx.xxx.24479 > 90.130.70.73.21: tcp 0
13:05:06.766410 IP 90.130.70.73.21 > 93.57.xxx.xxx.24479: tcp 20
13:05:06.766447 IP 93.57.xxx.xxx.24479 > 90.130.70.73.21: tcp 0
13:05:06.772561 IP 93.57.xxx.xxx.24479 > 90.130.70.73.21: tcp 14
13:05:06.817096 IP 90.130.70.73.21 > 93.57.xxx.xxx.24479: tcp 0
13:05:06.817115 IP 90.130.70.73.21 > 93.57.xxx.xxx.24479: tcp 26
13:05:06.817145 IP 93.57.xxx.xxx.24479 > 90.130.70.73.21: tcp 0
13:05:10.066607 IP 93.57.xxx.xxx.24479 > 90.130.70.73.21: tcp 16
13:05:10.111300 IP 90.130.70.73.21 > 93.57.xxx.xxx.24479: tcp 34
13:05:10.111368 IP 93.57.xxx.xxx.24479 > 90.130.70.73.21: tcp 0
13:05:11.043716 IP 93.57.xxx.xxx.24479 > 90.130.70.73.21: tcp 7
13:05:11.128910 IP 90.130.70.73.21 > 93.57.xxx.xxx.24479: tcp 0
13:05:12.783654 IP 90.130.70.73.21 > 93.57.xxx.xxx.24479: tcp 23
13:05:12.783690 IP 93.57.xxx.xxx.24479 > 90.130.70.73.21: tcp 0
13:05:14.296534 IP 93.57.xxx.xxx.24479 > 90.130.70.73.21: tcp 26
13:05:14.341011 IP 90.130.70.73.21 > 93.57.xxx.xxx.24479: tcp 0
13:05:14.341168 IP 90.130.70.73.21 > 93.57.xxx.xxx.24479: tcp 51
13:05:14.341196 IP 93.57.xxx.xxx.24479 > 90.130.70.73.21: tcp 0
13:05:14.350410 IP 93.57.xxx.xxx.24479 > 90.130.70.73.21: tcp 6
13:05:14.395146 IP 90.130.70.73.20 > 93.57.xxx.xxx.54046: tcp 0
13:05:14.395513 IP 93.57.xxx.xxx.54046 > 90.130.70.73.20: tcp 0
13:05:14.436943 IP 90.130.70.73.21 > 93.57.xxx.xxx.24479: tcp 0
13:05:14.440036 IP 90.130.70.73.21 > 93.57.xxx.xxx.24479: tcp 37
13:05:14.440067 IP 93.57.xxx.xxx.24479 > 90.130.70.73.21: tcp 0

Thanks.

sasa1

@Rico
yes unfortunately I am forced to use the ftp client because it is used in a script.
Thanks.

johnpoz

And that is useless, other than this which looks like your active data connection

13:05:14.395146 IP 90.130.70.73.20 > 93.57.xxx.xxx.54046: tcp 0
13:05:14.395513 IP 93.57.xxx.xxx.54046 > 90.130.70.73.20: tcp 0

What was that prob a RST?? From your client most likely.. Open the sniff in say wireshark so you can gets some insight.. And you can view exactly what was in the control channel

Or bump the verbosity up so you can see the flags in the data.. I would assume that 1st one there from source port 20 is Syn, since there only the 1 return i would assume RST! Which prob your client firewall saying F off ;)

sasa1

I should install wireshark on windows server ?
Thanks.

johnpoz

You just need to open the packet capture up.. Or increase the verbosity of in the packet capture so you can at least see that response to that source port 20 traffic - which would be the opening of the data channel in active mode... You see a response, but only 1 packet.. So that screams RST to me..

Example.. Here would be the handshake - you see the syn and syn,ack

If you look in the control.. you see the port command

Do the math (206*256)+131 = port 52867 - which is the port that the data channel was sent to from source port 20. That this shows my public IP and not the clients 192.168 address I know that the ftp proxy package is working and doing atleast that portion.. If pfsense had not opened that port would not of gotten anything back to the syn from the ftp server to open the connection.. Unless you setup some sort of reject rule on pfsense?? It would of just been dropped, that you see 1 packet in response just screams RST from the client..

90.130.70.73.20 > 64.53.x.x.52867: Flags [S], 
64.53.x.x.52867 > 90.130.70.73.20: Flags [S.],

I snipped out most of the info when you bump the verbosity up in your package capture - just to show the info you would be interested.. You see in mine the [S] (syn) and then the [S.] (syn,ack) back... I would bet big money yours was R for RST!! Which is tcp for F off! ;)

sasa1

I made a capture, I hope it will be of help.
Thanks.

johnpoz

That is not showing any data connection, that is just control.. So you told the server to connect to your IP 10.0.0.135.. Did the package change that to your public IP on the wan side? Cuz if it didn't then there would be NO way for that server to connect to you..

Your wan sniff clearly showed a data connection from that source port 20 to your random high.. That was most likely a syn, and then 1 packet was sent back in response.. What was that packet? Pfsense would NOT send back anything unless you specifically change the default or put in a specific reject which would be HORRIBLE thing to do on a wan connection that is connected to the public internet..

Also the use of NLST vs list is going to be an issue... NLST is hey give me that list of files over our previous data connection that was opened before... if there was no open data connection that would fail no shit!

Do a simple list command once you have logged in via your cmd line..

sasa1

Hi,
I tried to run NLST but it tells me that the command is not valid.
Thanks.

johnpoz

Why would you run NLST, just do a LS it will then open a data channel.

sasa1

when i run LS i get the following message:
ftp> ls
200 PORT command successful. Consider using PASV.
425 Failed to establish connection.
ftp>

Thanks.

johnpoz

And we have gone over this and over this! I have shown you examples of how to trouble shoot it!

sasa1

sorry but unfortunately I did not understand how to solve this problem.
how can i get the list of files?

I'm sorry but I haven't understood what the solution is.
Thanks.

johnpoz

The solution is to do a sniff and validate that your active package is changing the IP and port of your connection and that you see the data connection come in from the ftp server..

If passive works, then use something that will allow you to script with passive. Say the suggested winscp application. Or lftp or any of the other tools available that actually support passive mode. Which the built in ftp of windows does not.

Rico

Is your FTP script hardcoded somewhere or why do you still try the Windows build-in FTP Client?
Scripting FTP with WinSCP is really 5-10min and it just works.

-Rico

johnpoz

Not sure why anyone would script a connection to a speedtest ftp server in the first place - there are much easier methods to check your internet connection and speed without having to script some ftp thing..

Maybe this is just an example site he is using to present his issue?

But ftp client in windows using active mode works just fine with the ftp package in pfsense (when setup correctly) and no other issues that could prevent it from working.. But without some basic troubleshooting, you can not determine where the issue is.. A couple of simple sniffs will show you were the problem is.. Quite possible its a local firewall..

In one sniff he does show what appears to be an inbound data connection to his public IP. But then on another sniff (on the client) he shows no inbound data connection.

The response to the connection to the wan only shows 1 packet response - I am guessing that was a RST.. But pfsense would not send an RST (at least not out of the box)..

13:05:14.395146 IP 90.130.70.73.20 > 93.57.xxx.xxx.54046: tcp 0
13:05:14.395513 IP 93.57.xxx.xxx.54046 > 90.130.70.73.20: tcp 0

I have gone over how to view the details of the ftp conversations.. You can check the firewall logs, you can view the states created.

example - here are the firewall logs showing that it allowed traffic for the data connections when in active mode.

If this basic troubleshooting is above his understanding, I would suggest he hire someone, or get a netgate support contract and they can assist in finding the root cause of the problem.

Do you have this checked in your ftp proxy setup

Its possible the windows ftp client requires the source for data to come from source port 20..

It could be a just a problem with the client, it could be maybe the port is in use that the client is trying to use? Active ftp through nat is problematic at best.. If the port being used is the problem, your going to have to use a different client that always setting which port to use..

sasa1

@johnpoz unfortunately I am not the one to decide which ftp client to use.
The software developers told me that they cannot change the ftp client immediately and for this reason I am forced to use Windows ftp client.

how can I validate the package?

Thanks.

sasa1

@johnpoz
yes the ftp speedtest is only an example.

On the ftp server to which the script connects I have the following error message:

ftp> ls
200 PORT command successful.
425 Can't build data connection with host : "x.x.x.x" Error : Connection refused
ftp> quit

I also tried to enable the parameter:
Rewrite Source to Port 20
but the result does not change.
Thanks.