FTP Proxy / Nat dependency Bug



  • Sullrich,

    This is based on previous thread: MS FTP on DMZ not working for WAN Access [[url]http://forum.pfsense.org/index.php/topic,1879.0.html]

    Tried to update the thread with this but it was already locked.

    There is a bug in the ftp proxy startup.  It has to have the FTP Nat in place when rebooted to start the ftp proxy.  But the ftp connection will not work until you delete the Nat entry.

    example:

    • Add FTP Nat / which auto adds 2 default firewall rules
    • Reboot
    • FTP Proxy is started … FTP connection will not work
    • Delete Nat / Leave firewall rules
    • FTP connection works fine

    I think it should be looking for the ftp firewall rules on startup versus the Nat to start the proxy.  That means every time you reboot you have to re-add the Nat just to make sure the proxy gets started, then remove it after started to make the FTP connection work.

    example:

    • Add FTP Nat to auto add 2 default firewall rules / or enter firewall rules manually
    • Delete Nat rule if used in prior step
    • Reboot
    • FTP Proxy is started based on firewall rules
    • FTP connection works fine


  • You are clearly overthinking this!

    Leave the NAT entry alone, it is required…. Stop removing it!



  • No one is overthinking anything!  These are the facts… they have been applied and tested with my configuration.

    I have been in the business for 18 years as a software developer, so I know a little about building and testing software.  I am not here to argue, only trying to provide feedback from my experience to help make the product better.

    Bottom line is the FTP connection will NOT work with the NAT entry in place.  Remove it, based on the previous post (after the reboot) and works fine.

    If anyone else has experienced this issue then respond to this post to back up my results.



  • I have the same exact configuration as you in 2 locations.  Leaving the entry in place and rebooting works fine for me… So I really don't know what your doing wrong but its working fine on my machines.

    And the firewall was designed to NEED that entry in place.  If you want to continue to remove the NAT entry then you are on your own...



  • Maybe you have a newer build than me.  This is based on the following version: Version: RC2g



  • I am running RC2h.



  • I will try to run a fetch tonight for the upgrade to see if that fixes the issue and post back.



  • I just tested this with a client sitting at wan connecting to a ftp server at lan. Enabled ftp proxy at wan, added a portforward for ftp to the internal server: works. rebooted, tried again: works. Must be related to MS  :P



  • @hoba:

    I just tested this with a client sitting at wan connecting to a ftp server at lan. Enabled ftp proxy at wan, added a portforward for ftp to the internal server: works. rebooted, tried again: works. Must be related to MS  :P

    Configuration is different.  FTP is on Opt1 (in my case my DMZ) not LAN.

    WAN –> LAN
            --> DMZ (Opt1) -- > FTP

    And no it's not an MS issue.  Let's remain objective here, instead of subjective... just because you have ill feeling towards MS products for whatever reason doesn't prove relevant in solving the issue.

    It is a proxy/firewall issue.  Always worked fine before pfsense with 2 other routers.  Nothing on the network or ftp server has changed except that.

    Like I said I will upgrade to the new build tonight and test again.



  • @timb0311:

    And no it's not an MS issue.  Let's remain objective here, instead of subjective… just because you have ill feeling towards MS products for whatever reason doesn't prove relevant in solving the issue.

    It was a joke, lighten up!  Holger doesn't even speak english as his native language.



  • Upgraded to Version RC2h.  Same problem.  Can't use ftp until the NAT port forward is removed.

    You can connect and login when NAT is in place, which I already stated in previos post, but you can't send or receive data.  Command line freezes after trying to do a dir listing:
    ftp> dir
    500 Invalid PORT Command.
    150 Opening ASCII mode data connection for /bin/ls.
    _ <–- freezes here

    Again, the only way to get is working with my config is to follow this sequence:

    1. Delete any NAT/FW Rules for FTP port 21
    2. Re-add NAT for FTP 21 with auto FW Rules
    3. Reboot
    4. Delete NAT
    5. Everything works
    6. If you need to reboot you need the NAT rule in place to start the proxy on the correct Ips.  And you have to repeat this process from step 1, you can't just re-add the NAT rule and reboot.

    Working config renders:
    ftp> dir
    200 PORT command successful.
    150 Opening ASCII mode data connection for /bin/ls.
    01-24-06  06:26PM

    <dir>          XXXXXXX
    01-24-06  05:20PM

    <dir>          XXX
    03-09-06  04:07PM                38400 XXXX.doc
    06-02-06  02:07AM

    <dir>          XXXXX
    03-03-06  04:19PM

    <dir>          XXXXXXXX
    226 Transfer complete.
    ftp: 297 bytes received in 0.02Seconds 18.56Kbytes/sec.

    Somewhat off topic, but also noticed very High CPU usage since doing the upgrades... pegs out to 100% quite frequently.  No special packages just default install.

    </dir>

    </dir>

    </dir>

    </dir>



  • I just tried that again with OPT1 interface. Worked directly after configuring it. Rebooted 4 times, worked after every reboot out of the box. Tried active and passive mode. What to try next?

    (this time without joke, hope it is ok for you now)



  • Don't really know.  I guess there is something else missing you two have configured on your setup that I don't.  Any options checked or unchecked?  Advanced Outbound NAT on Opt1?  Other special setups? … like VIP etc?

    I have spent a lot of hours testing this to narrow down the sequence of what is causing it... but haven't found a way to resolve it.

    Any suggestions?  Maybe you two can email your xml config files so I can take a look to see what is different from mine?  Or maybe post it here, unless it is a production environment setup with public IPs, then email will do.  I just thought it would help others if it were posted.



  • I used a vanilla RC2h. Configured OPT1, added a pass all at OPT1, enabled ftpproxy at WAN. Added a host with ftp-server behind OPT1. Added a portforward at Interface WAN, protocol ftp, destination host with ftp-server, port ftp, autoadd firewallrule checked. saved. applied. worked. rebooted. worked. Nothing special about that setup.



  • Same simple setup here… with the exception of a few other port forwards for web, mail, voip.

    Tried removing the pass all rule from the DMZ (opt1), rebooting, then adding the ftp setup. Issues still the same.... can login but can't transfer until nat forward removed.  Used same repair sequence to resolve it until a reboot.



  • To me deleting the FTP port forward makes sense.  The ftp proxy resides on the loopback address and it is responsible for passing ALL communication to and from the backend ftp server and handle IP translations.  With the port forward still in place it is trying to bypass the ftp proxy, and my guess IP addresses not getting translated for the passive client.



  • That is not correct.  The FTP proxy listens on the public ip address and automatically adds port forwards to punch holes in the firewall.

    It does not listen on loopback or have anything to do with loopback in this case.  Furthermore when pfSense detects that a item is being forwarded to port 21 and the helper is on, it does not install a pf rdr rule and starts pftpx to listen on the public address pointing back to the internal ip of the ftp server.

    Really not sure why your setup doesn't work but I've tested this and Holger has tested and tested again and at this point if it doesn't work maybe you should look at using a different firewall as there is nothing else that I can do at this point.

    Sorry.



  • The fix quits working after 4-5 days anyway… proxy shuts down.

    If the loopback has nothing to do with it then why the rules with the loopback address for the dmz (sis2) and lan (sis1) interfaces for ftp traffic:

    $ pfctl -s rules | grep ftp
    anchor "ftpsesame/" all
    pass in quick on sis2 inet proto tcp from any to 127.0.0.1 port = ftp keep state label "FTP PROXY: Allow traffic to localhost"
    anchor "ftpproxy" all
    anchor "pftpx/
    " all
    pass in quick on sis1 inet proto tcp from any to 127.0.0.1 port = ftp-proxy keep state label "FTP PROXY: Allow traffic to localhost"
    pass in quick on sis1 inet proto tcp from any to 127.0.0.1 port = ftp keep state label "FTP PROXY: Allow traffic to localhost"
    pass in quick on sis0 inet proto tcp from any port = ftp-data to (sis0) port > 49000 user = 62 flags S/SA keep state label "FTP PROXY: PASV mode data connection"
    pass in quick on sis0 inet proto tcp from any to 10.0.x.180 port = ftp keep state label "USER_RULE: NAT WAN --> FTP Server"
    pass in quick on sis0 proto tcp from any to any port = ftp flags S/SA keep state label "USER_RULE: NAT WAN --> FTP Server"

    Another thing that doesn't make sense with your explanation.  The firewall NAT setup to forward from wan to dmz host on port 21.  Then you have the ftp proxy listening on the wan and forwarding to the dmz host on port 21.  Seems like a conflict to me.

    I would still like you to post or email a working xml config.  If you say you have a working config then you wiill not mind sharing.  And there must be something not the same in our configs.



  • @timb0311:

    The fix quits working after 4-5 days anyway… proxy shuts down.

    If the loopback has nothing to do with it then why the rules with the loopback address for the dmz (sis2) and lan (sis1) interfaces for ftp traffic:

    $ pfctl -s rules | grep ftp
    anchor "ftpsesame/" all
    pass in quick on sis2 inet proto tcp from any to 127.0.0.1 port = ftp keep state label "FTP PROXY: Allow traffic to localhost"
    anchor "ftpproxy" all
    anchor "pftpx/
    " all
    pass in quick on sis1 inet proto tcp from any to 127.0.0.1 port = ftp-proxy keep state label "FTP PROXY: Allow traffic to localhost"
    pass in quick on sis1 inet proto tcp from any to 127.0.0.1 port = ftp keep state label "FTP PROXY: Allow traffic to localhost"
    pass in quick on sis0 inet proto tcp from any port = ftp-data to (sis0) port > 49000 user = 62 flags S/SA keep state label "FTP PROXY: PASV mode data connection"
    pass in quick on sis0 inet proto tcp from any to 10.0.x.180 port = ftp keep state label "USER_RULE: NAT WAN --> FTP Server"
    pass in quick on sis0 proto tcp from any to any port = ftp flags S/SA keep state label "USER_RULE: NAT WAN --> FTP Server"

    These are OUTGOING FTP.  LAN -> WAN.  Nothing to do with WAN -> LAN.  The last 2 allow the traffic that has been rdr'd by the pftpx helper.

    @timb0311:

    Another thing that doesn't make sense with your explanation.  The firewall NAT setup to forward from wan to dmz host on port 21.  Then you have the ftp proxy listening on the wan and forwarding to the dmz host on port 21.  Seems like a conflict to me.

    Read the pftpx code before you make these accusations, please.

    @timb0311:

    I would still like you to post or email a working xml config.  If you say you have a working config then you wiill not mind sharing.  And there must be something not the same in our configs.

    I will set it up one more time and send config.xml but this is a complete waste of my time quite frankly, I've already spent 7+ hours on this issue for you.



  • Not counting my time  ;)

    And I described you my setup in detail starting from a vanilla install. There is no special mystique config that you need. Few simple steps I described and it works.



  • Okay, here's the config.xml.  I initially forgot that interfaces -> wan disable ftp helper was not checked and panic'd but after that it sprung to life as it should have:

    <pfsense><version>2.3</version>
    <lastchange><theme>metallic</theme>
    <system><optimization>normal</optimization>
    <hostname>pfSense</hostname>
    <domain>local</domain>
    <dnsserver><dnsallowoverride><username>admin</username>
    <password>$1$dSJImFph$GvZ7.1UbuWu.Yb8etC0re.</password>
    <timezone>Etc/UTC</timezone>
    <time-update-interval>300</time-update-interval>
    <timeservers>pool.ntp.org</timeservers>
    <webgui><protocol>http</protocol>
    <certificate><private-key></private-key></certificate></webgui>
    <disablenatreflection>yes</disablenatreflection>
    <enablesshd>yes</enablesshd>

    <maximumstates></maximumstates></dnsallowoverride></dnsserver></system>
    <interfaces><lan><if>le0</if>
    <ipaddr>192.168.1.1</ipaddr>
    <subnet>24</subnet>
    <media><mediaopt><bandwidth>100</bandwidth>
    <bandwidthtype>Mb</bandwidthtype></mediaopt></media></lan>
    <wan><if>le1</if>
    <mtu><media><mediaopt><bandwidth>100</bandwidth>
    <bandwidthtype>Mb</bandwidthtype>
    <spoofmac><ipaddr>dhcp</ipaddr>
    <dhcphostname></dhcphostname></spoofmac></mediaopt></media></mtu></wan></interfaces>
    <staticroutes><pppoe><pptp><bigpond><dyndns><type>dyndns</type>
    <username><password></password></username></dyndns>
    <dhcpd><lan><enable><range><from>192.168.1.100</from>
    <to>192.168.1.199</to></range></enable></lan></dhcpd>
    <pptpd><mode><redir><localip></localip></redir></mode></pptpd>
    <ovpn><dnsmasq><enable></enable></dnsmasq>
    <snmpd><syslocation><syscontact><rocommunity>public</rocommunity></syscontact></syslocation></snmpd>
    <diag><ipv6nat></ipv6nat></diag>
    <bridge><syslog><nat><ipsecpassthru><enable></enable></ipsecpassthru>
    <rule><protocol>tcp</protocol>
    <external-port>21</external-port>
    <target>192.168.1.69</target>
    <local-port>21</local-port>
    <interface>wan</interface>
    <descr>FTP</descr></rule></nat>
    <filter><rule><type>pass</type>
    <descr>Default LAN -> any</descr>
    <interface>lan</interface>
    <source>
    <network>lan</network>

    <destination><any></any></destination></rule>
    <rule><interface>wan</interface>
    <protocol>tcp</protocol>
    <source>
    <any><destination><address>192.168.1.69</address>

    <port>21</port></destination>
    <descr>NAT FTP</descr></any></rule>
    <rule><interface>wan</interface>
    <protocol>tcp</protocol>
    <source>
    <any><destination><network>wanip</network>
    <port>21</port></destination>
    <descr>NAT FTP</descr></any></rule></filter>
    <ipsec><preferredoldsa></preferredoldsa></ipsec>
    <aliases><proxyarp><wol><installedpackages><revision><description>/interfaces_wan.php made unknown change</description>
    <time>1157493006</time></revision></installedpackages></wol></proxyarp></aliases></syslog></bridge></ovpn></bigpond></pptp></pppoe></staticroutes></lastchange></pfsense>



  • Ok good, here is the problem.  After comparing configs, which we should have done a long time ago.  Would have saved us both lots of testing hours.

    <disablenatreflection>yes</disablenatreflection> which maps to System > Advanced > Disable NAT Reflection > checked.

    I had this unchecked, so I could access our websites running on the dmz from the lan using their public dns names.  With this unchecked this causes the problem with the ftp.  With it checked works fine.

    So my next question is how can I get these to work together so I can access the websites from the lan?



  • Interesting.  I suppose we will want to ignore reflection entries for port 21.  I will check into it.



  • Ok let me know what you find out.



  • Please replace /etc/inc/filter.inc with http://www.pfsense.com/~sullrich/filter.inc using diagnostics -> edit file.

    Then run /etc/rc.filter_configure from diagnostics -> command prompt

    Hopefully the reflection entries for port 21 will be gone now.



  • That seemed to fix it.



  • Yay!

    I'll commit.  Thanks for testing.



  • Thanks for fixing this!! I also had problems with FTP previously and had disable nat reflection unchecked. After replacing filter.inc ftp works. timb0311 good catch about the nat reflection.

    When you say you committed it, I am assuming this will be included in the next release after RC2i.



  • It already is included in the latest snapshots: http://pfsense.com/~sullrich/1.0-SNAPSHOT-09-07-06/


Locked