ftp client passive mode

johnpoz

200 PORT command successful. Consider using PASV.
425 Failed to establish connection.

And what port was trying to be used... Sniff on pfsense and look and see!

Try a different client that gives you better logging, like filezilla which will show you the port command sent. So you can see what IP and port... Then sniff on pfsense - is the proxy changing it on your wan.. Is the port your telling to connect to already in use? etc..

Your not policy routing out some vpn are you, etc. What is the make up of your setup... If it working on 1 network.. clearly it works, etc.. so you have to figure out what other issue is there..

sasa1

I tried with filezilla and a strange thing happens, if I use the domain name it gives me an error if instead I use the IP address it works:

Stato: Risoluzione dell'indirizzo IP speedtest.tele2.net in corso
Stato: Tentativo di connessione non riuscito con "EAI_NONAME - Nome nodo e nome server non forniti, o sconosiuti".
Errore: Impossibile collegarsi al server
Stato: In attesa di un nuovo tentativo...
Stato: Connessione a 90.130.70.73:21...
Stato: Connessione stabilita, in attesa del messaggio di benvenuto...
Stato: Server non sicuro, non supporta FTP su TLS.
Stato: Il server non supporta caratteri non ASCII.
Stato: Accesso effettuato
Stato: Lettura elenco cartelle...
Stato: Elenco cartella di "/" completato

is very strange !

johnpoz

My guess is you typo'd the name... simple to test if resolves or not.. do a dig or or nslookup, or whatever your fav dns tool is..

$ dig speedtest.tele2.net

; <<>> DiG 9.16.0 <<>> speedtest.tele2.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8563
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;speedtest.tele2.net.           IN      A

;; ANSWER SECTION:
speedtest.tele2.net.    0       IN      A       90.130.70.73

;; Query time: 8 msec
;; SERVER: 192.168.3.10#53(192.168.3.10)
;; WHEN: Sun Mar 29 10:31:06 Central Daylight Time 2020
;; MSG SIZE  rcvd: 64

Or maybe you put in url like http:// not sure.. what your doing wrong.

Can not tell from what you posted if your using active or passive. Pretty sure filezilla defaults to passive.. Which we have been over already multiple times!!

sasa1

the strange thing is this..that the name is correctly resolved !!

nslookup speedtest.tele2.net
Server: one.one.one.one
Address: 1.1.1.1

Risposta da un server non autorevole:
Nome: speedtest.tele2.net
Addresses: 2a00:800:1010::1
90.130.70.73

with filezilla, using the IP address, it works both in active and in passive mode.

johnpoz

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..

sasa1

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.

johnpoz

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..

sasa1

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.

johnpoz

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..

sasa1

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.

johnpoz

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.

Rico

Why would you use the Windows FTP Client anyway? Because of scripting? Then check out WinSCP...

-Rico

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.