FTP behind pfSense
-
I'm seeing an issue with an ancient FTP server behind a pfSense firewall… sorry can't make any changes to SFTP, active FTP, or anything else unfortunately. The previous firewall, an IPCOP, was working fine but it died and I have been unable to recreate the magic with pfSense. I followed the site below and even tried numerous suggestions from the forums. We are also unable to make any changes to the FTP server because we have hardware devices uploading files to it. We presently have port 21 and a range of passive ports NAT-ed to the server and it works fine in passive mode for clients such as FileZilla, but we still receive an error "Server sent passive reply with unroutable address. Using server address instead." That appears to be what the hardware devices cannot handle vs. a smarter client like FileZilla. Any other suggestions? It's almost like I would need to change the packets mid-stream similar to what the FTP client helper proxy does, but on a reply from the server if that makes any sense. Any help would be appreciated. Thanks, Dallas.
https://doc.pfsense.org/index.php/FTP_without_a_Proxy
-
well your out of luck.. If your ftp server is not smart enough to send its public IP when its on a private IP. Helper was removed quite some time ago, this is what use to do that behind the scenes.
What ftp server are you using?
Guess you update ftp server that has feature of sending its actual public IP vs its rfc1918 address when its behind a nat. Go back to ipcop or some other distro/appliance with a ftp helper or revert to old version of pfsense that had the helper.
Why people continue to hold on to ancient deprecated protocols just blows my mind… You should of moved away from ftp 10 years ago for gosh sake..
sftp is FREE for any OS that I can think of, windows, linux, os x, bsd. Both servers and clients are available. What is the excuse to continue to use something that has been dead for years.. It is NOT secure, if your using ftps/ftpes there is no way for a helper to change the IP for you.
Guess another option would be to put the ftp server your using that is too stupid to let you set what IP to give its clients in its passive setup is to put it on on actual public IP.
-
Why people continue to hold on to ancient deprecated protocols just blows my mind… You should of moved away from ftp 10 years ago for gosh sake..
sftp is FREE for any OS that I can think of, windows, linux, os x, bsd. Both servers and clients are available. What is the excuse to continue to use something that has been dead for years.
I'll tell you exactly why. You're a potential customer of mine. I want you to download and try out my very expensive custom software that fits your niche requirements. You're very busy and I really want to make this as easy for you as possible. I know you run Windows, and even though you're a genius in your field, you are not a Windows expert or IT person. So I just need you to:
Go to blahblah.foo.com
Download this widget you've never heard of before
Install it on your work PC and hopefully not break any IT policies in the process
Configure this beastie like this….
Here is how you use it...OR
Click this link
THAT is why FTP hasn't already died, because it is the only file transfer protocol that Windows understand out of the box. Making a user go and download something and install it just so he can then go and download your thing and install it is an extra hoop that I don't want my potential customers going through.
-
"because it is the only file transfer protocol that Windows understand out of the box"
Click this link
http://host.domain.com, or better yet https://host.domain.com
There you go ftp is DEAD.. Files have been served up for how many years via http/https? Your talking about doing ftp in a browser in the first place which is crap way to do ftp for sure.
You sure not going to walk a client thru using the built in ftp cli in windows.. Which doesn't even support passive. Shoot most company firewalls don't even allow ftp outbound, etc.
-
That would be fine for a generic, one-size-fits-all download. However, for us every potential customer has exclusive custom bits and we control access to that, so I would have to configure a web server with user accounts and that's a lot more hassle and attack surface than I want to deal with. Some of our customers need to share large files with us, and some of our partners also transfer some large files like videos of seminars and trade shows etc. I have been toying with the idea of using a cloud filer like Box, Dropbox or ownCloud and using user accts within that, but I'm still recovering from a SAN crash from last week as well as the 50 other jobs I do here. While I generally share your disdain for FTP, it still has its uses. If Microshit had bothered to put a decent transfer client into Windows, we wouldn't be having this discussion.
-
Yeah, I understand FTP is less than ideal and that was my reference to SFTP or just about anything else on the planet for file transfer. This is for a customer and a scenario where the hardware only allows passive FTP (not active) so I'm extremely limited on what I can do as a workaround. Any yes, I am fairly certain I understand this quite well from a security perspective. ;-) Unfortunately, I also understand it from a customer perspective and their primary piece of software to run their business only works with this particular hardware and that piece of hardware only works with passive FTP. I would have killed it off years ago if I could have, but that isn't reality. Although support for this among firewall vendors is limited, the truth is that others do still support this functionality. I was simply hoping for a workaround that I was overlooking which would allow pfSense to do the same because it is far and away my preferred solution, but that doesn't appear to be the case. Nonetheless, some belittling and fairly lively discussion aside, I appreciate the confirmation. Thanks, Dallas.
-
What ftp server is in use? Have you contact the maker, is it even still active/supported?
I am confused to a setup that would prevent change on 1 side or the other. Even if you 2 specific pieces of hardware that run specific software can you not put in a ftp server in front on your side and then have this ftp server move the files to the other device via local network so does not matter that hardware ftp can only give its actual IP, etc.
so you have this
special_client - internet - yourftp - special_server
Or
special_client – special server ---- internet -- yourftp
or
special_client (private network) --- internet (vpn tunnel private network) --- special_ftpserver (private network)
I would think there are multiple ways to work around the issue of old pieces of crap hardware that were not designed for the current landscape, etc.
-
When i was using old pfSense version with passive FTP worked without any problems, now upgraded to 2.3.2 and i could not get it working again even using Ftp Client Proxy package. In Vsftp server there is possible to customize directive pasv_address which is used to specify ftp public IP, if this IP is set everything works well except there are problems if local network client wants to connect.
Then i made one more configuration file for Vsftp with other IP for local network usage and added IP alias to ifcfg network configuration. Now server is running two Vsftpd copies in the same time - one configured for WAN other for LAN and even Windows built in FTP client works without problems. Vsftp example LAN config.:
listen_address=192.168.0.10
pasv_address=192.168.0.10and WAN config.:
listen_address=192.168.0.11
pasv_address= ftp public IP -
The ftp client proxy package has nothing to do with passive ftp server behind pfsense.. It for active connection to servers from clients behind pfsense to server on the internet or wan of pfsense.
Why do you need 2 configurations for your server? Clients can use active connect.. While clients outside pfsense could use passive or active.
-
:) i already felt that I have not understood correctly meaning of this package. 2 configurations because i do not want problems with possible reconfiguration of ftp clients.