FTP Proxy / Nat dependency Bug

sullrich

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.

timb0311

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>

hoba

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)

timb0311

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.

hoba

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.

timb0311

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.

timb0311

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.

sullrich

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.

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"

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.

sullrich

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

hoba

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.

sullrich

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>

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

timb0311

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?

sullrich

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

timb0311

Ok let me know what you find out.

sullrich

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.

timb0311

That seemed to fix it.

sullrich

Yay!

I'll commit. Thanks for testing.

rsw686

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.

hoba

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