FTP Client problem
-
If you set 'Log Connections' in the proxy settings do you see firewall log entries for it?
Do you see blocked traffic from the FTP server?
You might try using a different FTP client as a test here such as Filezilla. That will show you exactly what it's doing.
Steve
-
is the checkbox set to move it up the higher on the rules?
Here just tested this
C:\WINDOWS\system32>ftp speedtest.tele2.net Connected to speedtest.tele2.net. 220 (vsFTPd 2.3.5) 200 Always in UTF8 mode. User (speedtest.tele2.net:(none)): anonymous 331 Please specify the password. Password: 230 Login successful. ftp> ls 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. 1000GB.zip 100GB.zip 100KB.zip 100MB.zip 10GB.zip 10MB.zip 1GB.zip 1KB.zip 1MB.zip 200MB.zip 20MB.zip 2MB.zip 3MB.zip 500MB.zip 50MB.zip 512KB.zip 5MB.zip upload 226 Directory send OK. ftp: 183 bytes received in 0.02Seconds 11.44Kbytes/sec. ftp>active works just fine with windows ftp client behind pfsense..
You can see where its allowed through the firewall with these rules
Jan 30 12:28:54 ► LAN (@0) 90.130.70.73:20 192.168.9.100:55659 TCP:S Jan 30 12:28:54 WAN (@0) 90.130.70.73:20 192.168.9.100:55659 TCP:SHere doing it again with sniff..
Notice the port command sent is my machine rfc1918 IP, the ftp client changes that to my public IP, and if you do the math on the command (217*256)+148 = 55700 which is the port the data channel is sent to..
-
@stephenw10
Trace: CControlSocket::SendNextCommand()
Trace: CFtpLogonOpData::Send() in state 0
Stato: Risoluzione dell'indirizzo IP x.y.eu in corso
Stato: Connessione a x.x.x.x:21...
Stato: Connessione stabilita, in attesa del messaggio di benvenuto...
Trace: CFtpControlSocket::OnReceive()
Risposta: 220 Microsoft FTP Service
Trace: CFtpLogonOpData::ParseResponse() in state 1
Trace: CControlSocket::SendNextCommand()
Trace: CFtpLogonOpData::Send() in state 5
Comando: USER pippo
Trace: CFtpControlSocket::OnReceive()
Risposta: 331 Password required
Trace: CFtpLogonOpData::ParseResponse() in state 5
Trace: CControlSocket::SendNextCommand()
Trace: CFtpLogonOpData::Send() in state 5
Comando: PASS **********
Trace: CFtpControlSocket::OnReceive()
Risposta: 230 User logged in.
Trace: CFtpLogonOpData::ParseResponse() in state 5
Trace: CControlSocket::SendNextCommand()
Trace: CFtpLogonOpData::Send() in state 9
Comando: OPTS UTF8 ON
Trace: CFtpControlSocket::OnReceive()
Risposta: 200 OPTS UTF8 command successful - UTF8 encoding now ON.
Trace: CFtpLogonOpData::ParseResponse() in state 9
Stato: Accesso effettuato
Trace: Measured latency of 5 ms
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Trace: CFtpLogonOpData::Reset(0) in state 14 -
@johnpoz I do not work, when I run "ls" I have the error message that I attach
-
I don't see any port or pasv command sent in that log... Just sniff on the wan and lan of pfsense while you doing this so you can validate what is happening... ftp control is in the clear so as you see above you can see exactly what is sent by the client in the control channel. If when you sniff on the wan side you will see the ftp package change your port command to your actual public IP
Is pfsense behind a NAT? Not going to work if behind a NAT..
Is the wan of pfsense on a public IP? Sniff while you do that test of ftp to speedtest.tele2.net
So we can see exactly what is happening.
-
yes, the computer is behind a NAT, it has a private IP address.
-
NO pfsense is its wan a rfc1918 or the is it public?
-
@johnpoz on pfsense I have wan interface e lan interface, on wan interface I have an public IP address.
-
Like I said do a simple sniff.. And you can see exactly what is going on..
Here sniff (diag, packet capture on my wan) you can see my login on port 21... See where the PORT command gets changed to my public IP..
Then here comes the data connection to the port in the the port command
(200*256)+175 = port 51375
-
This post is deleted! -
@johnpoz sorry I do not know how to capture the really useful information, in the figure I sent I deleted the private IP address that is shown in the capture
-
Dude are you hiding a 10.x.x.x address? Why??? They are private and do not route on the internet... That info is useless to anyone knowing what it is.. Its like telling you I live in the US.. or the planet Earth.. Notice how I didn't hide my 192.168.9.100 address ;) You can capture the info right on pfsense.. diagnostic menu packet capture.
Do the capture on your WAN interface so we can validate its getting changed to your public wan IP.. Then just download the capture and open with wireshark.
In wireshark just right click on say the syn of the control channel and say follow stream.
BTW, I am a mod so I can see your deleted post ;) There is ZERO reason to hide 10.0.0.18.. You need to validate that gets changed on your WAN.. This is why you need to do the sniff on the WAN of pfsense to validate your ftp package is working.
here
Then download and open with wireshark
-
@johnpoz here is the log, I hope it contains useful information.
Thanks.
-
So he sent data connect to port 51069, which is correct per the PORT command.. (199*256)+125 but no answer..
Did the package not create the firewall rule? Did it not get placed at the top like I asked before
Did the pfsense forward it, but your client didn't answer? Sniff on the LAN side now when you do the test.. We can see from the sniff that the PORT command was changed to your public IP with that 167.x.x.x
So yeah its very useful information.
What are your firewall rules on your WAN? Are you running packages like Snort or Pfblocker?
-
@johnpoz I have checked the "Early Firewall Rule" but I do not see any new rules in either LAN or WAN.
In Rules -> WAN I have only the default rules and I do not use Snot or similar packages.
Thanks.
-
Well from your sniff you can see that the data connection was sent on by pfsense - so its doing EXACTLY what it is suppose to do... Yet your client is NOT answering...
(193x256)+69 = port 49477
You see all the SYN to your clients IP 10.0.0.18... Why does it NOT answer? Host firewall?
So why would your client not answer. I can see that the port is not set to 20 as source.. But it was on your sniff on WAN, Its possible your client WANTS that... Click this in in the package
Now test it again.. Bet you works now.
-
@johnpoz with WIndows Firewall disable the ftp problem did not occur !
there was no need to check "rewrite source ..".
On the windows firewall do I have to enable traffic on high ports?
thank you -
You would need to enable the application ftp.exe in the firewall most likely.. I don't use windows firewall - I have it disabled on all my windows boxes.. They all reside on a SECURE trusted local network that is isolated from all the iot gear and and anything that gets touched by the outside.. No reason to run it.. Leave it off locally - but set to say if my wife takes laptop out to some hotspot it would be on, etc.
But yeah your not going to know what port the client tells the server to connect to... This is the reason for the ftp helper package. The firewall needs to view the control channel info.. And it needs to do 2 things, it needs to change the clients port command from the rfc1918 address to what the public IP is.. And it needs to open a firewall rule/port forward for the data channel traffic the server will send to that IP and port so it gets back to the client.
Your host firewall would need to make sure it allows for what looks like unsolicited traffic from the server when it starts the data connection in active mode.
Your much better off using a client that does passive.. Since in passive mode both the control and data channel are initiated by the client.. So no need for the ftp helper package, and no need for inbound firewall rules, etc.
-
Nice.
Interesting that it behaved differently with a different router. I imagine the windows firewall saw it as a new network.
Steve
-
yup its quite possible that it was turned off on the other network, and when put behind pfsense it switched to public, etc.
