FTP Client problem
-
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.
-
@sasa1
Hi.Just create Alias with your ftp servers IPs\names and then make fw rule on LAN when this Alias would be in Dst with needed ftp ports. Set this rule first by order.
-
huh? Dude you might want to actually read the thread before responding ;)
-
Um... yeah that would not have helped at all in this case. Traffic to any ftp server was already allowed and passing.
Steve
