RC3 and FTP
-
Yes, the FTP rules have been moved to after the USER RULES. Prior the system would allow FTP no matter what before the USER RULES. So what has happened is your restrictive LAN rules are now working correctly.
It's not a bug, it's a feature ;D
-
Just tested and it works fine. Thanks guys.
Turns out that I have a catch all rule on the LAN to send traffic over the OPT1 interface. As the ftphelper is WAN that did not help. Some FTP clients work with the rule hoba gave above, others - like Adobe GoLive - needed a bit of a catch all for the specific machine to ensure that all the traffic goes via WAN.
-
I'm also having a problem with internet FTP on RC3.
Issue
–----
We have an app that connnects to an ftp server in the traditional manner (i.e., non-passively)
-
A tcpdump from the WAN interface of pfsense shows that login is successful, but pfsense is not properly mapping the internal client IP to the external IP of the firewall
230 Login successful.
type I
200 Switching to Binary mode.
syst
215 UNIX Type: L8
PORT 10,1,0,51,63,34
500 Illegal PORT command.Configuration
–-----------
2 WAN interfaces, but only one has outbound NAT configured (other is solely for server external availability)
-
"Disable userland helper" is unchecked on all interfaces; ps shows that FTP helper is running on the LAN, and on all other internal interfaces as well
proxy 582 0.0 0.3 656 416 ?? Ss 7:17AM 0:00.38 /usr/local/sbin/pftpx -c 8021 -g 8021 <pf.sense.lan.address>proxy 598 0.0 0.4 656 452 ?? Ss 7:17AM 0:00.41 /usr/local/sbin/pftpx -c 8023 -g 8021 <pf.sense.int2.address>proxy 606 0.0 0.4 656 452 ?? Ss 7:17AM 0:00.41 /usr/local/sbin/pftpx -c 8024 -g 8021 <pf.sense.int3.address>* FTP RFC 959 data port violation workaround: Enabled
-
The rule allowing the FTP traffic out
* LAN net * ! DMZNetworks * * Default LAN ->anywhere but DMZsWhich should also cover hoba's directive:
@hoba:pass, proto tcp, source <localsubnet>, port any, destination 127.0.0.1, port any, gateway default
This way the ftphelper is reachable for the clients to handle the other needed ports. Also make sure the ftphelper is enabled at all interfaces that need outgoing ftp. Note that the ftphelper will send all ftp connections to the main WAN, it is not able to make use of policybasedrouting or loadbalancing.</localsubnet>
I suspect i'm doing something wrong?
Your kind insights are appreciated.</pf.sense.int3.address></pf.sense.int2.address></pf.sense.lan.address> -
-
-
2 WAN interfaces, but only one has outbound NAT configured (other is solely for server external availability)
-
"Disable userland helper" is unchecked on all interfaces; ps shows that FTP helper is running on the LAN, and on all other internal interfaces as well
proxy 582 0.0 0.3 656 416 ?? Ss 7:17AM 0:00.38 /usr/local/sbin/pftpx -c 8021 -g 8021 <pf.sense.lan.address>proxy 598 0.0 0.4 656 452 ?? Ss 7:17AM 0:00.41 /usr/local/sbin/pftpx -c 8023 -g 8021 <pf.sense.int2.address>proxy 606 0.0 0.4 656 452 ?? Ss 7:17AM 0:00.41 /usr/local/sbin/pftpx -c 8024 -g 8021 <pf.sense.int3.address>ps
pftpx</pf.sense.int3.address></pf.sense.int2.address></pf.sense.lan.address>
-
-
Is your ps list complete here ?
Check some other posts (threads) about FTP and you'll find out that one more important pftpx task isn't running (doesn't show up in the list above).
It's the one that actually maps your WAN:21 port to your LAN_IP:21 port.outbound
Whats syslog saying about pftpx (or: what says pftpx in the syslog) ?
-
Running on an embedded platform
-
Currently running bare RC3 (will patch up to RC3e at next reboot opportunity)
-
-
Applied all patches through RC3e, and after boot, still only see:
ps waux | grep ftp | grep -v grep
proxy 579 0.0 0.3 656 416 ?? Ss 8:45PM 0:00.01 /usr/local/sbin/pftpx -c 8021 -g 8021 <pfsense lan="" ip="">proxy 593 0.0 0.4 656 452 ?? Ss 8:45PM 0:00.01 /usr/local/sbin/pftpx -c 8023 -g 8021 <pfsense lan2="" ip="">proxy 601 0.0 0.4 656 452 ?? Ss 8:45PM 0:00.01 /usr/local/sbin/pftpx -c 8024 -g 8021 <pfsense lan3="" ip="">And no failure messages from pftpx in syslog. What are the conditions under which the missing task needs to run?</pfsense></pfsense></pfsense>
-
Shoot…
In my last post I was writing an answer based/concerning incoming FTP.
In your case, all is already up to handle outgoing ftp.
This must be a firewall question (or related) because 'from the box' FTP just works great - I use RC3e.
Using two internal interfaces this gives me:ps auwx | grep pftpx | grep -v grep
proxy 612 0.0 0.1 656 424 ?? Ss Fri12PM 0:00.47 /usr/local/sbin/pftpx -c 8021 -g 8021 192.168.1.1
proxy 29739 0.0 0.1 656 532 ?? Ss 5:17PM 0:00.00 /usr/local/sbin/pftpx -c 8022 -g 8021 192.168.2.1 -
To see some more info in the syslog, I killed all pftpx process, and restared them by hand like this:
killall pftpx
/usr/local/sbin/pftpx -D 7 -c 8021 -g 8021 192.168.1.1
/usr/local/sbin/pftpx -D 7 -c 8022 -g 8021 192.168.2.1
Remember, I have two interfaces.
I start - and stopped - a FTP session from a LAN client (192.168.1.15), the syslog output was then:
…
Oct 7 17:28:34 pftpx[30327]: #1 ending session
Oct 7 17:28:34 pftpx[30327]: #1 server close
#Oct 7 17:23:34 pftpx[30327]: #1 passive: client to server port 36285 via port 57466
Oct 7 17:23:27 pftpx[30327]: #1 FTP session 1/100 started: client 192.168.1.15 to server 64.193.213.135 via proxy 82.128.125.169
Oct 7 17:23:09 pftpx[30331]: listening on 127.0.0.1 port 8022
Oct 7 17:23:09 pftpx[30331]: listening on 127.0.0.1 port 8022
Oct 7 17:23:00 pftpx[30327]: listening on 127.0.0.1 port 8021
Oct 7 17:23:00 pftpx[30327]: listening on 127.0.0.1 port 8021
Oct 7 17:22:48 pftpx[29739]: pftpx exiting on signal 15
Oct 7 17:22:48 pftpx[29739]: pftpx exiting on signal 15
… -
To see some more info in the syslog, I killed all pftpx process, and restared them by hand…
...
I start - and stopped - a FTP session from a LAN client (192.168.1.15)I did the same:
-
Killed all pftpx instantiations
-
Restarted them with the -D 7 argument
-
Tried an ftp connection. Result:
-
FTP connection fails with
and there was no indication in the syslog that pftpx was grabbing it.
I located man pages and source code for pftpx, and the problem that I seem to be finding is a lack of an rdr rule to redirect traffic on my primary LAN to the pftpx daemon:
nat-anchor "pftpx/" all
nat-anchor "natearly/" all
nat-anchor "natrules/" all
nat on WAN inet from lan.1.ip.addr/24 to any -> (sis3) round-robin
nat on WAN inet from lan.2.ip.addr/24 to any -> (sis3) round-robin
nat on WAN inet from lan.3.ip.addr to any -> (sis3) round-robin
rdr-anchor "pftpx/" all
rdr-anchor "slb" all
no rdr on LAN_3 proto tcp from any to <vpns>port = ftp
rdr on LAN_3 inet proto tcp from any to any port = ftp -> 127.0.0.1 port 8023
no rdr on LAN_2 proto tcp from any to <vpns>port = ftp
rdr on LAN_2 inet proto tcp from any to any port = ftp -> 127.0.0.1 port 8024
–---
<bunch of="" inbound="" rdr="" rules="" on="" wan="" interfaces="">------
rdr-anchor "miniupnpd" all</bunch></vpns></vpns> -
-
Apologies for the previous incomplete post.
To see some more info in the syslog, I killed all pftpx process, and restared them by hand…
...
I start - and stopped - a FTP session from a LAN client (192.168.1.15)I did the same:
-
Killed all pftpx instantiations
-
Restarted them with the -D 7 argument
-
Tried an ftp connection. Result:
-
FTP connects and logs in, but an "ls" fails with "500 Illegal PORT command rejected"
-
No indication in syslogs of any acivity with pftpx
-
==> pftpx is not getting connections from the primary LAN
I then located man pages and source code for pftpx, and understood that pf needs a port redirect rule for each internal network to redirect the ftp traffic to the proxy listening on port 802x.
==> Does this rule exists?
I find an rdr rule for two of my LANs, but none for my primary LAN (comments added are mine):
#pfctl -s nat
nat-anchor "pftpx/" all
nat-anchor "natearly/" all
nat-anchor "natrules/" all
nat on WAN inet from lan.1.ip.addr/24 to any -> (sis3) round-robin
nat on WAN inet from lan.2.ip.addr/24 to any -> (sis3) round-robin
nat on WAN inet from lan.3.ip.addr to any -> (sis3) round-robin
rdr-anchor "pftpx/" all
rdr-anchor "slb" all
no rdr on LAN_3 proto tcp from any to <vpns>port = ftp
rdr on LAN_3 inet proto tcp from any to any port = ftp -> 127.0.0.1 port 8023 # for one LAN
no rdr on LAN_2 proto tcp from any to <vpns>port = ftp
rdr on LAN_2 inet proto tcp from any to any port = ftp -> 127.0.0.1 port 8024 # for another LAN
–---
<bunch of="" inbound="" rdr="" rules="" on="" wan="" interfaces="">------
rdr-anchor "miniupnpd" allWhat I must discover
–-------------------
Why do I not have a NAT rule to provide transparent proxying on the primary LAN, when it works on the others?
- Could it be an artifact of once being configured with "disable userland proxy"?
-
Any other suggestions on how to make this happen?</bunch></vpns></vpns>
-
-
doesn't work for mi >:(
I have pfsense 1.0.1 and e ftp server listening in the port 2121 in the ip x.x.x.3
i try with Disable the userland FTP-Proxy application and enable, in wan and lan interfaces; but nothing happens
I create the nat forwardi and the rule (automatically) -
with my dual wan work only port 21 Active mode… if try to download or dir change with passive mode reply is very long time then disconnection. . . .
-
RC3 is quite old. I am locking this thread to avoid confusion.