ftp client passive mode
-
the strange thing is this..that the name is correctly resolved !!
nslookup speedtest.tele2.net
Server: one.one.one.one
Address: 1.1.1.1Risposta da un server non autorevole:
Nome: speedtest.tele2.net
Addresses: 2a00:800:1010::1
90.130.70.73with filezilla, using the IP address, it works both in active and in passive mode.
-
Yeah that doesn't make any sense at all... Local issue is you typo'd the name when you put it in to filezilla or had a space or something wrong... Works fine here with name.. filezilla would use the same dns as your OS... Unless its switched to trying to do doh or something?
So so these machines not even using pfsense for dns..
-
I have typed the name several times and it is the same that I use when I try the connection from the DOS client, I really can't understand!
however with Filezilla using the IP address I can make the ftp connection.what can I check to understand where the problem is in the ftp connection using the DOS client?
Thanks. -
Dude we already went over this - what are you NOT understanding about active vs passive??
the built in windows ftp client will NOT do passive - period! So your ftp proxy package would have to be setup.. Which multiple people have shown you works just fine..
-
I already installed the "ftp proxy client" package but it still doesn't work.
I should add that on other servers (which are in other datacenters) where I have configured pfsense in the same way, ftp access works fine.
I don't understand why only in this circumstance the access in ftp access doesn't work.
Thanks. -
Your in a DC.. You understand active only works when traffic can get back to you on the random high port that can be used.. Its quite possible that is not allowed upstream of pfsense.
all of which could be figured out in 30 seconds of sniffing that I suggested multiple posts back, but you seem unwilling to do the 30 second test, but just keep asking why it won't work without providing any actual info... Ie your sniff..
First step in troubleshooting is understanding how the protocol works active vs passive - again! Read the link I provided, then knowing how that works and the environment your in.. Which could cause that to break down... Sniff on pfsense to validate traffic is doing what its suppose to be doing..
-
in Windows, on the local firewall, I have enabled incoming traffic from ports 1024-65535.
I want to analyze the traffic to understand where the problem is, I only asked for help on how to get this information through sniffing.
Thanks. -
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.
-
Why would you use the Windows FTP Client anyway? Because of scripting? Then check out WinSCP...
-Rico
-
@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 0Thanks.
-
@Rico
yes unfortunately I am forced to use the ftp client because it is used in a script.
Thanks. -
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 0What 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 ;)
-
I should install wireshark on windows server ?
Thanks. -
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! ;)
-
I made a capture, I hope it will be of help.
Thanks.
-
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..
-
Hi,
I tried to run NLST but it tells me that the command is not valid.
Thanks. -
Why would you run NLST, just do a LS it will then open a data channel.
-
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.
-
And we have gone over this and over this! I have shown you examples of how to trouble shoot it!
