FTP not working since upgrading to version 2.5.1
-
just did the upgrade to PFSense 2.5.1 all went well but now it seems our internal software that needs to send packets via FTP is no longer working. We didn't even realize the EMR software was still using FTP and have voiced our concerns about this to the engineers. For now we need to have it working. Any suggestions on how to get ftp working?
-
Do you have the ftp proxy installed, configured and running?
This is required to use active ftp to server outside pfsense, since it will open up data port connection. If you are using passive to connect to the ftp, you wouldn't need this because the client makes the outbound connection for the data connection.
Do you see the login to the ftp server, and then just an error on the data connection?
-
@johnpoz just installed it found a post on similar issue with FTP...so i configured it as;
Proxy Enabled is checked
Local Interface LAN
Early Firewall Rules is checked
Anonymous Only default
Source Address default
Proxy Bypass: Source i see it has auto filled to one of our internal IPs should this need to be the server that is using the FTP?
Proxy Bypass: Destination should this also be as above
Bind Port has auto filled to port 21
Maximum Session default
Traffic Shaping Queue Default
rewrite source to Port 20 is checked
Idle Timeout default
Log Connections is checked. -
Proxy bypass would be for not using the proxy.. Be it either a local IP you don't want to use the proxy or for dest IP you don't want to proxy too, etc.
-
@johnpoz ok thanks we are going to do some tests now. I guess that makes sense thus the name "Proxy bypass" lol. we will test shortly and thanks so much for your fast replies :)
-
@nexxous said in FTP not working since upgrading to version 2.5.1:
still using FTP and have voiced our concerns about this to the engineers.
That is good - ftp should of died off 10 years ago. But finally its being deprecated more and more. Maybe browsers are finally pulling support, etc. Many sites are killing off their ftp servers, etc.
Sftp is secure, only 1 port needed.. etc.. Data and control channels have always been problematic with nat.
There really is no reason to still be using ftp.
-
@johnpoz 100% agree and brought this up with the EMR techs geez we didn't realize they still even use FTP in their software and worse of all it is sending sensitive data. So once we realized this I voiced our concerns with them having data like this sent out on an unsecured protocol wow...
-
@nexxous said in FTP not working since upgrading to version 2.5.1:
just did the upgrade to PFSense 2.5.1 all went well but now it seems our internal software that needs to send packets via FTP is no longer working
I'm using 2.5.1 for several weeks now.
And I have also a device in my network that upload an image to our company's web site.
It's actual a web cam page, with snapshots every 15 seconds.Just checked : it works well.
@nexxous said in FTP not working since upgrading to version 2.5.1:
We didn't even realize the EMR software was still using FTP
I somewhat solved the issue.
My (ftp) server - a host in a data center - only accepts incoming connections from my companie's WAN IP using port 21.
So, to break a way into my ftp server, you need to source your attack using an IP that I have right now.
Possible. If some manages to do so, he earned the right to 'pawn' my server.and have voiced our concerns about this to the engineers.
Don't do that !!!! They will come back with a $$$$ solution to solve the $$ problem.
-
@gertjan ftp is NOT a secured protocol and has not been for a long time no matter how you look at it. In this case they send and received data so one needs to be very cognizant of what is being seen for sure.
-
@nexxous Not even with TLS activated?
-
The problem with ftps, even if you do encrypt the data channel which is not always the case. It still uses active or passive for the data connection. And since the control channel is encrypted, it makes it that more difficult to do ftp through nat. Which is normally on both sides - server and client.
Since the firewall can not see the ports to be used for the data connection, and open up a firewall rule to allow the server to say to connect to the client. And you also run into problems with ftp server itself sending its rfc1918 address vs actual public - which the helper/proxy on the natting device could change to correct public IP, etc.
Sftp is the way to go.. You are sure everything is encrypted, and there is only 1 port to worry about.
-
@johnpoz data being sent to and from normal ftp can be considered unsecured i would change it to at least SFTP.
-
Nobody should be using ftp for really any reason these days.. It should of died off 10 some years ago. That it still around is just sad..
-
@johnpoz totally agree and as i indicated previously once we found out the EMR software is using FTP to submit data omg. We have strongly voiced our opinion on this and putting users data at risk like that is not acceptable...sounds like they are taking the advise and contacting the software engineers to develop other method...no shit. lol. So doing the upgrade to version 2.5.1 had a total unexpected win :)
-
@nexxous said in FTP not working since upgrading to version 2.5.1:
ftp is NOT a secured protocol and has not been for a long time no matter how you look at it
Yep, I know. Don't worry, I'm not advocating its use.
Just my 'excuse' : it's in a $ 2000 DVR devices hooked up to 16 cameras ( $ 250 each ) all over the site., using close to 6000 feet of coax cable.
It was fun to install all that, a decade ago. I have to redo it all using IP cams and a IP based DVR ..... yeah, will do that some where in the future.I'm sending over 2 snapshots of two camera's each 20 seconds to a Debian based chrooted FTP server.
These image are shown 'as is' by a web server. Here.
If needed, I could create a VPN tunnel just for that.To get back to the subject : My FTP client is behind a NAT (pfSense) and the server has no NAT or firewall, so there can't be any issues.
Because it's 'old' the FTP client doesn't understand IPv6 - using IPv6 would correct all FTP issues ;)
pfSense 2.4.5-p1, 2.5.0 or 2.5.1 are all equal - pfSense 2.5.1 did not change something. -
@gertjan said in FTP not working since upgrading to version 2.5.1:
using IPv6 would correct all FTP issues ;)
While it could help with some of the issue. You still have a problem with the data channel and some random ports and firewall rules ;) So unless you open up your client to the public net for all ports.. Still problematic - remember when ftp came out.. Firewalls really were not a thing ;)
-
@johnpoz
I'll be more specific :
IPv6 throws out of the windows all "passif ? actif ?" issues & misunderstanding.
Major security issues still stand.FTP itself is, of course, totally "not-done" these days.
It's used by people who do not want to think (so me probably included).
Its ancient. It should be part of the nice and sweat and bitter memories of the past.@johnpoz said in FTP not working since upgrading to version 2.5.1:
remember when ftp came out.. Firewalls really were not a thing
Yep : things like ISP home router 'firewalls' didn't exist as there were no ISP's.
We had a line with a "real" WAN Internet IP => range <= like a /30 or /28 - a couple of 'servers' and everybody was talking to everybody. Mail - 25 - ports were accessible to everybody, we could relay using who we wanted. The sick-minded didn't use the Internet back then. All was smooth and easy.
Then someone decides that an Internet access to every household would be fine.
Another one found out that 2^32 IP wouldn't make it far.
So a third one invented NAT/PAT. Dono if this guy merits a medal or a bullet.
And a nice network idea, designed to launch nukes and exchange university documents, became somewhat borked. I guess the NAT/PAT concept created a billion size group of people that 'thought' that they understood it. And so wrong they were. -
Yeah I get it while its still in use. And I agree laziness is top of list ;) What is sad is that your camera system is how old.. That they thought ftp was fine when it was designed is the real problem. While sure they could still have it as an "option" it doesn't support sftp? Or webdav or just plain https for moving files?
So pretty much the rest of the net is all encrypted these days.. But ftp - yeah lets send username and password in the clear, and not encrypt any of the data being sent. But someone "reading" a website public data - yeah that needs to be secured via https ;)
Not that long ago, many websites were just http, and only the login info was sent via https.
Asking for a IP of a public website for via a couple of udp packets - yeah lets wrap that in encryption and overhead of tcp..
Think we have gotten a bit off topic ;)
