FTP proxy with multiple public IPs

[artooro]

The FTP proxy package available in pfSense has the limitation of only supporting translation to a single public IP.

In an installation that I'm working on some connections need to go out via one IP and others via a 2nd IP.

I know that pfSense can't help me in this scenario, but I'm asking the question here as this is a limitation of pfSense and perhaps other users have found a workaround or some other solution.
For example is there something that you guys are running on the client side to do the PORT translation.

It seems like such as simple problem, that stupid ftp PORT command has to be translated to the correct public IP. There must be a simple FTP proxy that I can install on the client side that will do this, as the FTP client itself in this case does not support setting the external source IP.

Hoping for some ideas as if I don't get this solved today then pfSense may be going out.

[Derelict]

General advice is stop using FTP. It is not NAT-friendly. And requiring a port be open back in the other direction is, well, horrible design. Can they not use passive mode?

Otherwise, yeah, pfSense might not be a solution to your problem.

[artooro]

@Derelict Yeah I totally get that. Unfortunately it's dictated by a third party and I both can't do passive mode and can't switch away from FTP.

Was just hoping that since pfSense users have to deal with this, that there would be a non-pfSense solution that folks are using.

[Derelict]

Actually this is the first time I have seen it come up.

I don't think there is going to be a solution to your unique problem.

[johnpoz]

@artooro said in FTP proxy with multiple public IPs:

dictated by a third party and I both can't do passive mode and can't switch away from FTP.

Walk away would be my suggestion... Why deal with such parties. If they do not or can not support passive, then have them use sftp..

Why can you not do passive? You can very easy setup a passive ftp server behind pfsense, or active server behind pfsense as well. And passive outbound is not going to be a problem.

You could always run 2 pfsense ;) 1 for each wan connection..

Why ftp will not die, when it should of died 10 some years ago is users/companies fail to push companies that do nonsense like this towards a more current solution.. Tell them sorry can not do business with that, will have to somewhere else to go... Whatever services they are providing that need files moved up or pulled down should offer multiple solutions.. sftp, https, rsync, etc. sure ok ftp for the behind the times... But them saying you can only use ftp to us, and it has to be active is just plain nonsense..

[Derelict]

When you are pretending to be the 300-lb gorilla in a business relationship you should at least be correct/current in your requirements.

[artooro]

Well guys, as the 300-lb gorilla I decided to write my own ftp proxy.
It's open source here: https://github.com/artooro/ftp-port-proxy

Problem solved. And yeah hopefully one day people stop using FTP.

[johnpoz]

You understand that doesn't do anything for the firewall right.. The ports have to be opened inbound to the client..

So is your client going to always use the same source port so you can forward it?

So your client connects to say 1.2.3.4, and port command was saying hey connect to me on 192.168.1.100, and sure the proxy can change that to 4.5.6.7 your pfsense wan IP.. What source port X?, how is the firewall going to then forward this traffic to 4.5.6.7 on port X to 192.168.1.100?

Here why can you not just use say active mode in filezilla client

So you setup the client to present the public IP that your gong to send it out, 4.5.6.7 in my example.. And source ports are always 6000 to 6010.. So you forward those ports to your clients actual IP 192.168.1.100

You policy route out traffic to 1.2.3.4 out the 4.5.6.7 wan.. No need for a proxy at all..

If you have multiple clients, you can set the next client 192.168.1.101 to use ports say 6011 to 6021.. and so on for more clients, and you setup the forwards to send those ports to .101..

This limitation can be overcome, depending - but that is not the issue really.. The issue is the hanging on such an antiquated method of transfer.. That for example with your proxy the control would have to be sent in the clear so the proxy can see the port command, so now your username and password is sent in the clear over the internet..

ftp was fine back in the early days of the internet, its not longer really a good solution..

[earlsmith]

This post is deleted!

[artooro]

Yeah I understand what I did doesn't do anything with the firewall. The firewall does an IPSec tunnel to the remote FTP server, which is NATed back to the internal server.
My proxy runs on that internal server and simply rewrites the PORT command to the public IP.

And the reason I had to do this is because the software can't use filezilla, wsftp, or any of those clients out there that have the active mode IP type of option. It's an old Java application that can't do anything else.

We certainly plan to move this to a more modern platform eventually but for now my proxy works and allows us to keep pfSense in the mix.

[johnpoz]

If you have a ipsec tunnel to where the ftp is.. Shouldn't freaking matter about nat at all. Why would public IPs be involved in a ipsec tunnels between locations?

Your setup gets odder and odder..

If I have 2 sites using rfc1918 space, and I want device A to talk to B - nat does not need to be involved.. Even if they were using public space inside their network.. As long as they know how to get back to your rfc1918 network through the tunnel there is no reason for natting.

If you take natting out of the equation then there is not an issue, its just firewall rules - that could just really be any any if you needed them too... You do not have to do the port forwarding and napt issues with forwarding port x through your firewall if your not natting the traffic. Could be as simple as firewall rule to allow talking to client IP from source port 20, etc.

[stephenw10]

When everybody is using 192.168.1.0/24 sometimes you are forced to NAT if you want any connectivity.

[johnpoz]

Nope - not forced, you making the call that easier and better to nat then change one side to use something different.. Not like rfc1918 is freaking limited in what address space you can use ;)