Navigation

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

    RC3 and FTP

    General pfSense Questions
    10
    27
    11458
    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.
    • S
      sh_man last edited by

      I upgraded to RC3 last night and killed all FTP access from LAN to WAN/OPT1 (using dual WAN setup). It worked fine with RC2 (I have rolled back to keep the users happy).

      Is there some config that I am missing that did not matter before RC3?

      1 Reply Last reply Reply Quote 0
      • Gertjan
        Gertjan last edited by

        To use a FTP server on a PC in your LAN - and make it accesible from 'the world', you should do just this thing:
        Create a NAT-Rule on the WAN interface, port 21 to the FTP server IP, port 21.
        Automaticlay two rules will be created in the firewal list.

        Check that you didn't disable the "FTP Helper … Disable the userland FTP-Proxy application" option on the Interfaces->WAN  & Interfaces->LAN.

        Afterwards, you'll see a

        ps auwx | grep pftpx | grep -v grep

        proxy    617  0.0  0.1  656  420  ??  Ss  Mon12PM  0:00.47 /usr/local/sbin/pftpx -c 8021 -g 8021 192.168.1.1
        proxy  30379  0.0  0.1  656  488  ??  Ss    6:33PM  0:00.00 /usr/local/sbin/pftpx -f 192.168.1.2 -b 83.193.54.47 -c 21 -g 21

        83.193.54.47 => (my) WAN IP
        192.168.1.2 => (my) LAN "FTP server" IP

        This is enough to make FTP accesible from the 'outside'.

        1 Reply Last reply Reply Quote 0
        • S
          sh_man last edited by

          Thanks for that - but I am trying to get from the LAn to FTP servers out on the web - not the other way round.

          Literally, if I use RC3 it does not work, and RC2 it does work. No other settings are changed.

          1 Reply Last reply Reply Quote 0
          • D
            databeestje last edited by

            does the rc3a update fix your problem?

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

              Works fine here without issues. Also this is funny as somebody says just the opposite in this thread: http://forum.pfsense.org/index.php/topic,2281.msg13273.html#msg13273

              1 Reply Last reply Reply Quote 0
              • J
                jeroen234 last edited by

                no problem here on rc3 rc3a or rc3b

                1 Reply Last reply Reply Quote 0
                • S
                  smeg9 last edited by

                  I too am experiencing this problem, cannot access FTP sites on the internet, from within our LAN.
                  worked on beta2, but not on RC3

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

                    Everybody who is experiencing this problem please test the following:
                    Download and burn a RC3 livecd. Save your config.xml to a floppy to /conf/config.xml. Boot your machine up with floppy in drive and cdrom. Does it work then? If yes something broke somewhere along the upgrade(s). Reinstall pfSense with a fresh RC3 then (just hit option 99 and it will move your config.xml from the floppy over too).

                    1 Reply Last reply Reply Quote 0
                    • S
                      sullrich last edited by

                      Make sure the ftp helper is enabled on Interfaces -> LAN.

                      If this still does not work, reinstall.

                      1 Reply Last reply Reply Quote 0
                      • S
                        sh_man last edited by

                        Ok. Tried using RC3 livecd with current config - no dice. Still no FTP out to the net.

                        Installed RC3 from the livecd onto disk - complete reformat job. Then tried RC3a and RC3b - no change.

                        Have gone back to RC2.

                        All I can think of is that I have not set things up "properly" for FTP and that RC3 is a bit more strict.

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

                          Please send your config to holger <dot>bauer <at>citec-ag <dot>de. I'll have a look if I can see something obvious.</dot></at></dot>

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

                            Ok, I think I know what's going on. You have a restrictive setup at your LAN, only letting out certain ports. Port 21 is not enough to make ftp work. It uses some other ports after it has connected to the server too (depending on active and passive mode, portrange configured at the server and so on). Add a rule at LAN (and on any other interface where you need ftp to be working):

                            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.

                            Let me know if this works.</localsubnet>

                            1 Reply Last reply Reply Quote 0
                            • S
                              sullrich last edited by

                              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.

                              1 Reply Last reply Reply Quote 0
                              • S
                                sh_man last edited by

                                Thanks for that. I'll get on to sorting it in the morning! Too much like hard work to test from home ;)

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

                                  @sullrich:

                                  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

                                  1 Reply Last reply Reply Quote 0
                                  • S
                                    sh_man last edited by

                                    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.

                                    1 Reply Last reply Reply Quote 0
                                    • V
                                      Voami last edited by

                                      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 DMZs

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

                                      1 Reply Last reply Reply Quote 0
                                      • Gertjan
                                        Gertjan last edited by

                                        @Voami:

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

                                        1 Reply Last reply Reply Quote 0
                                        • V
                                          Voami last edited by

                                          @Gertjan:

                                          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

                                          @Gertjan:

                                          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)

                                          1 Reply Last reply Reply Quote 0
                                          • V
                                            Voami last edited by

                                            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>

                                            1 Reply Last reply Reply Quote 0
                                            • Gertjan
                                              Gertjan last edited by

                                              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

                                              1 Reply Last reply Reply Quote 0
                                              • Gertjan
                                                Gertjan last edited by

                                                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
                                                …

                                                1 Reply Last reply Reply Quote 0
                                                • V
                                                  Voami last edited by

                                                  @Gertjan:

                                                  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>

                                                  1 Reply Last reply Reply Quote 0
                                                  • V
                                                    Voami last edited by

                                                    Apologies for the previous incomplete post.

                                                    @Gertjan:

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

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

                                                    1 Reply Last reply Reply Quote 0
                                                    • C
                                                      cauly last edited by

                                                      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)

                                                      1 Reply Last reply Reply Quote 0
                                                      • O
                                                        OrCAD last edited by

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

                                                        1 Reply Last reply Reply Quote 0
                                                        • S
                                                          sullrich last edited by

                                                          RC3 is quite old.  I am locking this thread to avoid confusion.

                                                          1 Reply Last reply Reply Quote 0
                                                          • First post
                                                            Last post

                                                          Products

                                                          • Platform Overview
                                                          • TNSR
                                                          • pfSense
                                                          • Appliances

                                                          Services

                                                          • Training
                                                          • Professional Services

                                                          Support

                                                          • Subscription Plans
                                                          • Contact Support
                                                          • Product Lifecycle
                                                          • Documentation

                                                          News

                                                          • Media Coverage
                                                          • Press
                                                          • Events

                                                          Resources

                                                          • Blog
                                                          • FAQ
                                                          • Find a Partner
                                                          • Resource Library
                                                          • Security Information

                                                          Company

                                                          • About Us
                                                          • Careers
                                                          • Partners
                                                          • Contact Us
                                                          • Legal
                                                          Our Mission

                                                          We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                                          Subscribe to our Newsletter

                                                          Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                                          © 2021 Rubicon Communications, LLC | Privacy Policy