FTP Helper on the LAN interface
-
I would expect that to work unless the routing is wrong on that firewall. If it is you can probably add a static route for the FTP server in question via the other pfSense box.
Steve
-
@stephenw10 The dark side of using proxies is that you lose the IP of the original requestor. This is something that I did not take into consideration when using what pfSense does in the case of the WAN interface as an example.
As NAT is usually applied in the WAN interface most of the times, over that interface it already happens the 'proxy' conversion: the change the source IP of the packet with the public external IP. I do not want that side effect. What I was really after is what the RELATED keyword does in iptables. I was after something like:
iptables -A INPUT -p tcp -i eth0 --dport 21 -j ACCEPT
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPTIn this construct you do not alter the traffic flow. You only open the system for reverse connections and only for the specific, related, one. But there is no iptables in pfsense and I do not know if there is something alike that may have the same effect in the traffic.
-
That is pretty much what the proxy does.
You can have a chain of pfSense boxes and use ftp though them all then only difference I see with what you're doing is that the second box in the chain is not using WAN as it's upstream connection for the ftp traffic.
How is it failing for you right now? You see traffic blocked? You see it leaving via the wrong interface?
Where do you need to see the original source IP that you do not?
Steve
-
@stephenw10 Hi Steve. Thanks for your reply. The fail happens as soon as the client issues the PORT command and closes the connection waiting for the FTP server to call back to the tcp port that it was told to use.
The first pfSense (the one in the branch office closest to the user connecting to the FTP server, call it pfs1) has no problems with this because pfs1 takes all that traffic and sends it through the VPN so no problems at all forth and back. The VPN has no restrictions regarding traffic flows. All ports open inside the VPN.
When the intermediate pfsense (pfs2) receives the encrypted traffic (it is the VPN endpoint) decrypts it, looks in its routing table and deliver it (through the LAN interface) to the last pfSense in the chain (pfs3) that, in turn, applies NAT and delivers it to the external internet FTP server. All this working fine, no drops no wrong deliveries.
pfs3 must have the proxy ftp listening in the WAN interface as it is able to track the connection back from the FTP server and traffic flows. pfs2, on the contrary, has not tracked anything over the FTP session so it blocks the incoming replies and drops the traffic. It can be seen in the firewall log: denied by default rule.
I have configured a rule in the LAN interface of pfs2 to allow this traffic (allow any:20/tcp to any:any/tcp) so now FTP replies are able to pass but this is a security hole: any with this knowledge will be able to send unsolicited traffic through pfs2 to the branch office.
If I configure the ftp proxy in the LAN interface of pfs2 as suggested (a clever suggestion by the way) then I am sure that it will work too without the need of that insecure rule but at the price of losing who made the FTP request. The net monitors in pfs3 will not be able to match FTP sessions to IPs as ALL traffic will come from the same IP, the one of the LAN interface of pfs2 where the proxy is applied.
Of course this can be avoided by monitoring in pfs2 too but it should be far more convenient not to have to do all this just to let ftp connections flow back through it by adding traffic inspection (the conntrack RELATED option).
There are only these options: open ports, track the connection or proxy it. If pfSense has any mecanism to track them then should will be the preferred way, else proxy it if you can or are allowed then open ports. If any of those solutions does not apply then tell the useer not to use FTP anymore :-)
-
Mmm, OK. Well as you say the ultimate solution here is to stop using FTP. But until then those are the choices; more secure or more visibility. I'd have to assess exactly what risk opening port 20 to other internal hosts is. I'm thinking it's probably not huge. Especially when compared to using FTP over the public internet.
You could probably lock it down further, does that rule need to be any destination IP? Does it need to be any source IP, how many servers are they connecting to?Steve
-
Not that I am complainig about the features of such a good platform that pfSense. But I would like to see this feature in some future release.
FTP will probably not receive any love at this point.
The real solution is for your side to put in the money and effort to get off of that old, antiquated, obsolete, insecure, firewall-unfriendly protocol that is active FTP.
Even IF you use ip_conntrack_ftp in iptables that is only going to be effective as long as the protocol is unencrypted and insecure with usernames and passwords flying about in-the-clear etc.
-
@stephenw10 Hi Steve. I think that the rule is the only one possible if you don't want to be all day chasing system cn¡hanges. There are several users receiving their IPs by DHCP from a class C pool so they may change their IP without notice (I know that there exist reservations but not applied to client PCs) and there are several (do not know how many) servers. I understand that we can lock it down and even put a rule for each client PC so that control granularity can be as fine as you want but I think this does not deserve the time and effort involved.
The actual security is what it is reasonable to be (easily explainable if you have to) for the kind of service we have to deal with without not having to be all day hooked onto the firewall if we do not have any other automatic mechanism to achieve that goal.
Thanks for your implication in this.
-
WTF does that have to do with moving away from the DEAD protocol that is FTP??
That has to be some sort of google translate gibberish? Or your stoned? ;)
-
@derelict You are right. The fact that the protocol is insecure does not change the fact that is is still being used and that there are those that offer the service the ones that have to change it. We have to deal with that.
Perhaps if certificates had not been so difficult and expensive until the entry of LetsEncript in the field...
-
Like many things there is a balance between security and convenience to be drawn.
Having the clients nominate the servers the need to connect to doesn't seem that unreasonable to me. But, inconvenient for them....
Steve
-
The bottom line is if you need Active FTP clients behind a firewall and the services provided by the FTP_Client_Proxy service are not a good fit, pfSense is not for you.
The availability of certificates has nothing to do with the fact that when a client requests a file, it tells the server where to connect to and that reverse server-to-client connection has to be opened on the client side firewall. Or firewall(s) in your case. SSH has been around for 20+ years. SFTP for 15+. They still insist on using FTP.
