Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Running into road block during setup of FTP

    Scheduled Pinned Locked Moved General pfSense Questions
    5 Posts 2 Posters 3.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      MerikFynd
      last edited by

      Hello every one.

      I have just recently converted over from M0n0wall to PFSense 1.0.1.  I started from a blank configuration and have setup everything, but FTP successfully.

      I have 1 WAN IP on a /24 subnet and want to setup access to a single FTP on my LAN.

      I don't care about PASV, but if I can use it I'm happy.

      I followed this method:

      http://wiki.pfsense.com/wikka.php?wakka=IncomingFTPHowTo

      I had these Nat/Rules created by the process:

      "
      NAT: WAN  TCP  21 (FTP)  192.168.0.X (ext.: 70.74.XX.XX)  21 (FTP)

      Rules: TCP  *  *  192.168.0.x  21 (FTP)  * 
      Rules: TCP  *  *  WAN address  21 (FTP)  * 
      "

      I get this result:

      220-ftp.siliconunlimited.com X2 WS_FTP Server 5.0.0 (2367122271)
      < 220-SiliconUnlimited FTP
      < 220 ftp.siliconunlimited.com X2 WS_FTP Server 5.0.0 (2367122271)

      USER xxxxxxx
      < 331 Password required

      PASS *****
      < 230-user logged in
      < 230-Welcome to the SiliconUnlimited FTP
      < 230 user logged in

      PWD
      < 257 "/" is current directory

      • Entry path is '/'

      CLNT Testing from http://www.g6ftpserver.com/ftptest from IP xx.xx.xx.94
      < 500 illegal command

      • QUOT command failed with 500

      • Connection #0 to host xx.xx.xx.94 left intact

      • Closing connection #0

      The FTP server logs this "ftp.xxxxx.com P(BadCommand)" on the session

      PFsense logs this:

      "
      Jan 31 01:00:39 pftpx[14085]: #1 client reset connection
      Jan 31 01:00:39 pftpx[14085]: #1 client reset connection
      "

      I deleted all NAT/ Rules for port 21.  Verified is proxy application enabled on WAN and recreated rules.  Still the same error.

      toggling "FTP RFC 959 data port violation workaround" made no difference

      I tried the http://faq.pfsense.com/index.php?sid=390714&lang=en&action=artikel&cat=1&id=178&artlang=en
      Method as well.

      I get to the point where I try to create the "CARP" virtual IP and get this:

      "
      Firewall: Virtual IP Address: Edit

      The following input errors were detected:

      Sorry, we could not locate an interface with a matching subnet for xx.xx.xx.95/24. Please add an ip in this subnet on a real interface.
      "

      My Wan interface page reads as this:

      "
      IP address xx.xx.xx.94   
      Subnet mask 255.255.255.0 
      Gateway xx.xx.xx.1 
      "

      My understanding or misunderstanding is that I should be picking an IP in the same /24 subnet as the WAN physical interface.  I have tried many variations on Subnet mask and IP to no effect

      As this does not work I am at a loss on how to proceed.

      Any additional information anyone needs I would be happy to provided.  I have spent a couple of days on this searching the forum trying to identify my mistake, but I can not identify it.  I wish I had a better grounding in FreeBSD, but my expertise lies elsewhere.

      1 Reply Last reply Reply Quote 0
      • H
        hoba
        last edited by

        You don't need CARP unless you need additional IPs at your WAN interface. Please delete all created portforwards/firewallrules and start over:

        • Make sure ftphelper at WAN is enabled (interfaces>wan)
        • Then add a portforward for just port 21 and make sure autocreate firewallrule is checked when saving (firewall>nat, portforward tab)
        • It should not that it created an additional rule for the ftp helper at 127.0.0.1 in the red infobox
        • apply

        Now it should work. If not please post the created firewallrules for this ftp. Do you use multiwan (policybased routing or loadbalancing)?

        1 Reply Last reply Reply Quote 0
        • M
          MerikFynd
          last edited by

          All NAT/Rules for firewall concerning FTP deleted.

          Interfaces -> WAN -> FTP Helper
          Disable the userland FTP-Proxy application "Unchecked"
          Block private networks "Checked"
          Block bogon networks "Checked"

          Firewall -> NAT -> Port Forward

          Created TCP Port Forward from WAN interface port 21 to LAN FTP server IP port 21 with "Auto-add a firewall rule to permit traffic through this NAT rule" = Checked

          Received this message:

          "The changes have been saved. Please note that we have added an additional rule for the FTP helper.
          The NAT configuration has been changed.
          You must apply the changes in order for them to take effect. "

          See this new Port Foward rule:
          WAN  TCP  21 (FTP)  192.168.0.X (ext.: XX.XX.XX.94)  21 (FTP)  SiliconUnlimited FTP

          Hit Apply

          Under Firewall -> Rules I see

          These 2 new rules

          Rules: TCP  *  *  192.168.0.x  21 (FTP)  * 
          Rules: TCP  *  *  WAN address  21 (FTP)  *

          Do you use multiwan (policybased routing or loadbalancing)?  None of these condiftions are true.

          End result = Exactly the same error as previously reported.

          Here is a couple of chunks of "cat /tmp/rules.debug" if it might help:

          FTP Proxy/helper

          FTP proxy

          rdr-anchor "pftpx/*"
          nat on $wan from 192.168.0.0/24 port 500 to any port 500 -> (dc0) port 500
          nat on $wan from 192.168.0.0/24 to any -> (dc0)

          table <vpns>{  }

          User-defined rules follow

          pass in log quick on $wan proto tcp from any to {  192.168.0.y } port = 25 flags S/SA keep state  label "USER_RULE: NAT Siliconunlimited SMTP"
          pass in log quick on $wan proto tcp from any to {  192.168.0.x } port = 80 flags S/SA keep state  label "USER_RULE: NAT SiliconUnlimited Website"
          pass in log quick on $wan proto tcp from any to {  192.168.0.y } port = 81 flags S/SA keep state  label "USER_RULE: NAT Siliconunlimited WebMail"
          pass in log quick on $wan proto tcp from any to {  192.168.0.y } port = 110 flags S/SA keep state  label "USER_RULE: NAT Siliconunlimited POP3"
          pass in log quick on $wan proto tcp from any to {  192.168.0.y } port = 143 flags S/SA keep state  label "USER_RULE: NAT Siliconunlimited IMAP"
          pass in log quick on $wan proto tcp from any to {  192.168.0.x } port = 443 flags S/SA keep state  label "USER_RULE: NAT SiliconUnlimited SSL Website"
          pass in log quick on $wan proto tcp from any to {  192.168.0.y } port = 444 flags S/SA keep state  label "USER_RULE: NAT Secure WebMail access"
          pass in quick on $wan proto { tcp udp } from any to {  192.168.0.z } port = 6346 keep state  label "USER_RULE: NAT Shareaza Access port"
          pass in quick on $lan from 192.168.0.0/24 to any keep state  label "USER_RULE: Default LAN -> any"
          pass in quick on $wan proto tcp from any to {  192.168.0.x } port = 21 keep state  label "USER_RULE: NAT SiliconUnlimited FTP"
          pass in quick on $wan proto tcp from any to xx.xx.xx.94 port = 21 keep state  label "USER_RULE: NAT SiliconUnlimited FTP"

          VPN Rules

          pass in quick on fxp0 inet proto tcp from any to $loopback port 8021 keep state label "FTP PROXY: Allow traffic to localhost"
          pass in quick on fxp0 inet proto tcp from any to $loopback port 21 keep state label "FTP PROXY: Allow traffic to localhost"
          pass in quick on dc0 inet proto tcp from port 20 to (dc0) port > 49000 user proxy flags S/SA keep state label "FTP PROXY: PASV mode data connection"

          enable ftp-proxy

          Fix sites that violate RFC 959 which specifies that the data connection

          be sourced from the command port - 1 (typically port 20)

          This workaround doesn't expose us to any extra risk as we'll still only allow

          connections to the firewall on a port that ftp-proxy is listening on

          pass in quick on dc0 inet proto tcp from any to (dc0) port > 49000 user proxy flags S/SA keep state label "FTP PROXY: RFC959 violation workaround"

          And here is the last few log entries:

          Jan 31 06:59:53 siliconwall php: /firewall_nat.php: FTP proxy disabled for interface LAN - ignoring.
          Jan 31 06:59:53 siliconwall php: /firewall_nat.php: FTP proxy disabled for interface opt1 - ignoring.
          Jan 31 06:59:53 siliconwall php: /firewall_nat.php: FTP proxy disabled for interface opt2 - ignoring.
          Jan 31 06:59:54 siliconwall pftpx[42417]: listening on xx.xx.xx.94 port 21
          Jan 31 06:59:54 siliconwall pftpx[42417]: listening on xx.xx.xx.94 port 21
          Jan 31 07:02:16 siliconwall pftpx[42417]: #1 client reset connection
          Jan 31 07:02:16 siliconwall pftpx[42417]: #1 client reset connection

          Is there any other information that might possibly be helpful?  Just to clarify the FTP server worked perfect under monowall and has not be changed in anyway.</vpns>

          1 Reply Last reply Reply Quote 0
          • M
            MerikFynd
            last edited by

            Errr  Don't waste any more time on this.  Turns out my problem thus far has not been rooted in my configuration.  I just tried connecting to this FTP from another location and it is working correctly.

            I was using this site to test my configuration remotely.

            http://www.g6ftpserver.com/en/ftptest

            I don't know why it doesn't work but and it still doesn't, but I can connect to the FTP fine all be it slower than normal from this site.

            Just to pull something useful from this fiasco for future gernerations what do you guys use to test Inbound connections to something like FTP when you are behind the firewall you are trying to test?

            1 Reply Last reply Reply Quote 0
            • H
              hoba
              last edited by

              You always should try these kind of things from externally. especially such crappy protocols like ftp  ;)

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.