Running into road block during setup of FTP

MerikFynd · Jan 31, 2007, 8:16 AM

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.

hoba · Jan 31, 2007, 8:36 AM

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

MerikFynd · Jan 31, 2007, 2:13 PM

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>

MerikFynd · Jan 31, 2007, 3:07 PM

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?

hoba · Jan 31, 2007, 9:18 PM

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