FTP inbound - issues.



  • Yes, yet another FTP question. Sorry about that.

    INB4 the "FTP sucks, join the 20th century" let me say that my choices are constrained, I'm being sent data from giant monolithic institutions that have used FTP since the 70's and by gawd, if it was good enough then it's good enough now…. :) I'd love to ditch it. I can't.

    I switched to a pfSense cluster today from a Cisco and all in all, great improvement. The stuff I thought might bite me (VPN's) worked like a charm. The stuff I didn't even think about, however, did bite me.

    The unsolved issue - accessing an FTP server set up in our DMZ. Clients can connect, but get no data, can send no files and time out. In active mode, "425 Unable to build data connection: No route to host". Passive mode times out.

    I'm probably the reason it doesn't work, due to lack of knowledge; I'm a generalist forced to do FW work since nobody else is available. So here I am.

    Briefly about the setup; our ISP sends both our normal WAN range (19x.xxx.xxx.xxx) and our dmz range (21x.xxx.xxx.xxx) to the WAN address. I then have a DMZ interface on the inside, and since the DMZ IP range is there, the default route should find the servers there, afaik. On the DMZ net, there's a machine with an FTP server.

    The firewall rules are in the WAN section (as that is where the DMZ inbound traffic shows up) and the rules seem to work (port 21 to the above IP of the above server.)

    On the DMZ net, there's currently a rule that allows any to any (specific blocks are on the LAN net, since DMZ traffic shouldn't be allowed to talk inwards.)

    But for some reason, while the users can connect, they can't list data or transfer files. Any ideas?

    The other issue was that outgoing FTP from an ancient custom client just didn't work. I was slamming my head against the table by the time I found the FTP Proxy package, which was apparently ripped out of anything newer than 2.1.5. Adding that package in and enabling it for the LAN solved that. 50% fewer users now want me dead!



  • Is it a passive or active FTP connection?  If active, the server sends a connection back to the client, which must be permitted by the firewall at both ends.  NAT also tends to break it.  Does it work with a browser?  Browsers use passive mode, so if it works with a browser, but not FTP client, then active vs passive is the problem.


  • Rebel Alliance Global Moderator

    So no route to host in active..  The client is prob giving its rfc1918 address?  And there is no helper on pfsense to change that IP they send to the IP they actually are using.

    In passive mode, the server would tell the client what IP and port to go.  You would have to make sure your server gives out your public IP, and you forward the ports the server is using for the passive range.

    You can validate the exact problem, like what IP the client is sending for the client to connect back to by just simple sniff.. Ftp would be in the clear unless your using ftps or ftpes??  Sounds unlikely.

    The key to getting ftp to work through a firewall and especially one that nats is understanding the difference between an active and passive connection.

    http://slacksite.com/other/ftp.html



  • Thanks for the replies! I'm fairly conversant with active vs passive; it's my understanding that if the LAN (or DMZ, in this case) is set up with a rule to allow any to any (ie, wide open going out), and the WAN has a rule that allows port 21 in, active should work. No route to host sounds off.

    However, I did change the settings in ProFTPd to masquerade as the actual address of the server just in case (it's reachable on the 213.xxx.xxx.xxx address, there's no NAT, and I specified the passive ports between 20000 and 21000. )

    Edit: As it happens I couldn't masquerade since not only does the server get connected to from the outside, it also gets connected to from the inside… yea, don't ask. Fortunately, the machine has a proper IP on the DMZ net that resolves from the outside, so I didn't need it anyway.

    Anyway, with passive set to on, a specific port range specified and those ports opened up in the firewall, the connectivity was restored. I don't know how the previous firewall handled it since it definitely wasn't set up passive before (the former firewall was outsourced and I didn't really have full insight into the thing), but as long as I can get it working in passive (and it seems I can) I'm a happy camper. Thanks for the pointers.

    PS. Yes, FTP must die. Going to try to actively work on it, maybe I can talk them into SFTP or something.... hey, miracles have happened before.


  • Rebel Alliance Global Moderator

    The active issue could be on their end.. They have to allow that traffic back in..  Could be their client not telling you the correct public IP..

    If your curious sniff on the traffic and see what is going on int he control channel.  Yes you are correct with active into your server behind pfsense, as long as you forward 21 and allow outbound on the ports they use it should work.  Unless they send wrong IP in the port command or their firewall doesn't open up the ports.

    For example when you go outbound on active, you need the ftp package to open up the inbound for the server to connect back.  It looks in the control channel for the port and creates the firewall rules for you, etc.  And makes sure the IP you send is the correct one and not some rfc1918 address.  My "guess" would be they are senidng you rf1918