Running into road block during setup of FTP



  • 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.



  • 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)?



  • 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>



  • 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?



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


Log in to reply