SOLVED: FTP server behind pfsense without helper



  • I'm trying to setup FTP server in my LAN, and I can't get it working in passive mode. I don't want to use ftp helper on WAN, as I need to log real IP addresses (who connects to FTP).

    The structure: WAN-pfsense-LAN-server(with private IP)
    pfsense 1.2.3
    FTP server (Filezilla) is set up correctly to use external IP of pfsense, and a range of passive ports 50001-50030.
    FTP helper is disabled on all interfaces, except LAN. There are 2 port forwards:

    WAN   TCP   21 (FTP)   192.168.34.5 (ext.: xxx.14.168.6) 21 (FTP)
    WAN TCP 50001 - 50030 192.168.34.5 (ext.: xxx.14.168.6) 50001 - 50030

    And two rules:
    TCP   *   *   *   21 (FTP)   *        
    TCP * * * 50001 - 50030 *

    The result is that I can connect and login from outside, then FTP server sends correct passive response like this:
    227 Entering Passive Mode (xxx,14,168,6,195,92)
    The suggested port is ok (195*256+92=50012). But then nothing happens, client times out. No block entries in the firewall log, no other suspicious activity.

    I've read everything I could find in this forum, and I know what is passive mode, and how it works. I already did a lot of configurations using simple port forwards on various routers, and it worked every time. I don't get it why it is such a problem on pfsense. I tried deleting all ftp rules, enabling/disabling ftp helper on all interfaces, then recreating rules - nothing.

    There is one catch however: some time ago I edited config.xml through webgui to specify media options for WAN interface (10mbps). Later it was not needed, so I changed it back to media autoselect. Since then every time I change ftp helper option for WAN, it reverts to the same old 10mbps setting. I tried to delete config.cache, but it didn't help.



  • Hint: somehow the server's command "227 Entering Passive Mode (xxx,14,168,6,195,92)" becomes "227 Entering Passive Mode (192,168,34,5,19,140)" on the client side! Who the hell is rewriting ftp commands?  ???



  • @Snoopy:

    Hint: somehow the server's command "227 Entering Passive Mode (xxx,14,168,6,195,92)" becomes "227 Entering Passive Mode (192,168,34,5,19,140)" on the client side! Who the hell is rewriting ftp commands?  ???

    Where were you seeing the xxx,14,168,6 address.  Did you look at the packets.

    Based on the 192,168,34,5, I'd guess your FTP server is giving out it's real address.

    Most servers have a way to configure the address the hand out.

    Cheers.



  • @EddieA:

    @Snoopy:

    Hint: somehow the server's command "227 Entering Passive Mode (xxx,14,168,6,195,92)" becomes "227 Entering Passive Mode (192,168,34,5,19,140)" on the client side! Who the hell is rewriting ftp commands?  ???

    Where were you seeing the xxx,14,168,6 address.  Did you look at the packets.

    Based on the 192,168,34,5, I'd guess your FTP server is giving out it's real address.

    Most servers have a way to configure the address the hand out.

    Cheers.

    I see it in Filezilla's log and window GUI. And Filezilla IS configured to use public ip for passive transfers. I'll try to sniff some packets later.



  • Make sure ftp helper is really turned off on all interfaces.

    netstat -an
    pfctl -sn
    


  • @Evgeny:

    Make sure ftp helper is really turned off on all interfaces.

    netstat -an
    pfctl -sn
    
    $ pfctl -sn
    nat-anchor "pftpx/*" all
    nat-anchor "natearly/*" all
    nat-anchor "natrules/*" all
    nat on em0 inet from 192.168.34.0/24 port = isakmp to any port = isakmp -> (em0) port 500 round-robin
    nat on em0 inet from 192.168.34.0/24 port = 5060 to any port = 5060 -> (em0) port 5060 round-robin
    nat on em0 inet from 192.168.34.0/24 to any -> (em0) port 1024:65535 round-robin
    nat on em0 inet from 10.0.0.0/24 port = isakmp to any port = isakmp -> (em0) port 500 round-robin
    nat on em0 inet from 10.0.0.0/24 port = 5060 to any port = 5060 -> (em0) port 5060 round-robin
    nat on em0 inet from 10.0.0.0/24 to any -> (em0) port 1024:65535 round-robin
    rdr-anchor "pftpx/*" all
    rdr-anchor "slb" all
    no rdr on em2 proto tcp from any to <vpns>port = ftp
    no rdr on em2 proto tcp from <onetoonelist>to any port = ftp
    rdr on em2 inet proto tcp from any to any port = ftp -> 127.0.0.1 port 8021
    rdr on em0 inet proto tcp from any to xxx.14.168.6 port = ftp -> 192.168.34.5
    rdr on em0 inet proto tcp from any to xxx.14.168.6 port 50001:50030 -> 192.168.34.5 port 50001:50030
    rdr on em2 inet proto tcp from any to ! (em2) port = http -> 127.0.0.1 port 80
    rdr-anchor "imspector" all
    rdr-anchor "miniupnpd" all
    binat on em0 inet from 10.0.0.5 to any -> xxx.14.168.5</onetoonelist></vpns> 
    

    As far as I understand, helper is on for em2 (LAN) only, and that's how I want it. Anything else unusual?



  • @Snoopy:

    There is one catch however: some time ago I edited config.xml through webgui to specify media options for WAN interface (10mbps). Later it was not needed, so I changed it back to media autoselect. Since then every time I change ftp helper option for WAN, it reverts to the same old 10mbps setting. I tried to delete config.cache, but it didn't help.

    This was fixed by deleting /tmp/config.cache a few times. Strange though.



  • Sorry for replying to myself  :) but this is driving me crazy.

    Firstly, "pfctl -sn" returns exactly the same data whether helper on WAN is enabled or disabled. Shouldn't it reflect WAN config change?

    Secondly, I kill pftpx process, there's no one listening on port 21 in pfsense, but IP is still getting rewrited somewhere in between FTP server and external client.



  • Problem solved. I didn't mention that the server running Filezilla is Win2003 DC with RRAS enabled. It seems that RRAS has some kind of FTP helper/filter too, and it must be playing with IP addresses. I tried a few different FTP softwares, and the result on this particular machine was the same.

    I didn't want to waste any more time on this, so I just moved FTP server to another machine without RRAS. No more problems, passive works as it should.


Locked