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

    Debug.pfftpproxy=1 to enable LAN to WAN FTP

    2.1 Snapshot Feedback and Problems - RETIRED
    16
    66
    24.1k
    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.
    • A
      athurdent
      last edited by

      @ermal:

      Can you please be more specific on what does not work?

      How to reproduce:
      Just setup a fresh pfSense install, plug one (Win 7) device behind it and open a freshly installed Firefox. Key in

      ftp://dd-wrt.com/others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676/
      

      and wait for "425 Failed to estabilsh connection".

      1 Reply Last reply Reply Quote 0
      • D
        doktornotor Banned
        last edited by

        @athurdent:

        How to reproduce:
        Just setup a fresh pfSense install, plug one (Win 7) device behind it and open a freshly installed Firefox. Key in

        ftp://dd-wrt.com/others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676/
        

        and wait for "425 Failed to estabilsh connection".

        This works perfectly fine with SpeedCommander, Total Commander and FlashFXP (both active and passive mode). Sorry, but FF is braindead FTP "client".

        Active:

        
        Connect to: (04.07.2013 11:53:54)
        hostname=dd-wrt.com
        username=anonymous
        startdir=/others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676/
        dd-wrt.com=83.141.4.210
        220 Welcome to DD-WRT FTP service.
        USER anonymous
        331 Please specify the password.
        PASS ***********
        230 Login successful.
        SYST
        215 UNIX Type: L8
        FEAT
        211-Features:
         EPRT
         EPSV
         MDTM
         PASV
         REST STREAM
         SIZE
         TVFS
         UTF8
        211 End
        HELP SITE
        214-The following commands are recognized.
         ABOR ACCT ALLO APPE CDUP CWD  DELE EPRT EPSV FEAT HELP LIST MDTM MKD
         MODE NLST NOOP OPTS PASS PASV PORT PWD  QUIT REIN REST RETR RMD  RNFR
         RNTO SITE SIZE SMNT STAT STOR STOU STRU SYST TYPE USER XCUP XCWD XMKD
         XPWD XRMD
        214 Help OK.
        OPTS UTF8 ON
        200 Always in UTF8 mode.
        CWD /others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676/
        250 Directory successfully changed.
        Connect ok!
        PWD
        257 "/others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676"
        Get directory
        TYPE A
        200 Switching to ASCII mode.
        PORT 10,0,0,1,222,174
        200 PORT command successful. Consider using PASV.
        LIST
        150 Here comes the directory listing.
        Download
        Waiting for server...
        226 Directory send OK.
        
        

        Passive:

        
        Connect to: (04.07.2013 11:54:32)
        hostname=dd-wrt.com
        username=anonymous
        startdir=/others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676/
        dd-wrt.com=83.141.4.210
        220 Welcome to DD-WRT FTP service.
        USER anonymous
        331 Please specify the password.
        PASS ***********
        230 Login successful.
        SYST
        215 UNIX Type: L8
        FEAT
        211-Features:
         EPRT
         EPSV
         MDTM
         PASV
         REST STREAM
         SIZE
         TVFS
         UTF8
        211 End
        HELP SITE
        214-The following commands are recognized.
         ABOR ACCT ALLO APPE CDUP CWD  DELE EPRT EPSV FEAT HELP LIST MDTM MKD
         MODE NLST NOOP OPTS PASS PASV PORT PWD  QUIT REIN REST RETR RMD  RNFR
         RNTO SITE SIZE SMNT STAT STOR STOU STRU SYST TYPE USER XCUP XCWD XMKD
         XPWD XRMD
        214 Help OK.
        OPTS UTF8 ON
        200 Always in UTF8 mode.
        CWD /others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676/
        250 Directory successfully changed.
        Connect ok!
        PWD
        257 "/others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676"
        Get directory
        TYPE A
        200 Switching to ASCII mode.
        PASV
        227 Entering Passive Mode (83,141,4,210,241,176)
        LIST
        150 Here comes the directory listing.
        Download
        Waiting for server...
        226 Directory send OK.
        
        

        On that note, I must say pf/BSD does pretty impressive job here. Using active FTP from behind NAT has been just plain impossible with Linux/iptables-based firewalls.

        1 Reply Last reply Reply Quote 0
        • A
          athurdent
          last edited by

          @doktornotor:

          Sorry, but FF is braindead FTP "client".

          Sure, but it used to work with Firefox. Plus it works behind all of the other Firewalls/Routers I have tested (Checkpoint, ASA, some D-Link device, DD-WRT, AVM Fritz…)
          It's not only Firefox, Chrome does not work either.
          I don't really care, but the average surfer/user will. So I posted a way how to reproduce the issue for debugging purposes.

          1 Reply Last reply Reply Quote 0
          • D
            doktornotor Banned
            last edited by

            Yeah, FF, Chrome, IE, Safari and any other mainsteam browser are all braindead FTP clients. I'd suggest to take your issue with the browser developers. As for debugging, no debugging is possible without a session transcript (as posted above) - good luck getting anything like that from the browser - or some wireshark sniffing.

            1 Reply Last reply Reply Quote 0
            • A
              athurdent
              last edited by

              @doktornotor:

              On that note, I must say pf/BSD does pretty impressive job here. Using active FTP from behind NAT has been just plain impossible with Linux/iptables-based firewalls.

              modprobe ip_conntrack_ftp
              

              ;)

              1 Reply Last reply Reply Quote 0
              • D
                doktornotor Banned
                last edited by

                @athurdent:

                modprobe ip_conntrack_ftp
                

                ;)

                That does not really work (well or at all) with about half of FTP servers out there (a.k.a. waste of time).

                1 Reply Last reply Reply Quote 0
                • A
                  athurdent
                  last edited by

                  @doktornotor:

                  Yeah, FF, Chrome, IE, Safari and any other mainsteam browser are all braindead FTP clients. I'd suggest to take your issue with the browser developers. As for debugging, no debugging is possible without a session transcript (as posted above) - good luck getting anything like that from the browser - or some wireshark sniffing.

                  Well I already did put a lot of effort into debugging this problem if you look at post #11. If I find the time, I'll do that again with the lastest snapshots. For now I can only describe how to easily reproduce the issue for debugging purposes.

                  1 Reply Last reply Reply Quote 0
                  • jimpJ
                    jimp Rebel Alliance Developer Netgate
                    last edited by

                    The easiest way to get a session capture from the firewall itself is this:

                    # pkg_add -r tcpflow
                    # rehash
                    # tcpflow -c -i em0 port 21
                    

                    Get a capture from the LAN NIC, and the WAN NIC

                    Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                    Need help fast? Netgate Global Support!

                    Do not Chat/PM for help!

                    1 Reply Last reply Reply Quote 0
                    • G
                      ggzengel
                      last edited by

                      Better to capture the whole traffic to the (otherwise unused) destination ip.
                      Because the traffic shouldn'd use port 21 (neither src and dst) for data and that's the problem.

                      1 Reply Last reply Reply Quote 0
                      • jimpJ
                        jimp Rebel Alliance Developer Netgate
                        last edited by

                        It depends on which bit you're having an issue with.

                        tcpflow would show NAT/port translation errors a lot easier than digging through an entire capture. tcpflow prints out the plain text exchange between the client and server without having to dig through a binary capture; It gives you something you can just copy/paste as others have done earlier in this thread from FTP clients that actually work properly.

                        Getting all of the traffic to/from the target server would help find other issues (such as connections going to the wrong port).

                        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                        Need help fast? Netgate Global Support!

                        Do not Chat/PM for help!

                        1 Reply Last reply Reply Quote 0
                        • G
                          ggzengel
                          last edited by

                          But you don't see if server really connect from port 1234 to client port 2345 and the router expect this.

                          1 Reply Last reply Reply Quote 0
                          • jimpJ
                            jimp Rebel Alliance Developer Netgate
                            last edited by

                            Yes, but as I said, a different problem entirely. They are both helpful but in different ways.

                            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                            Need help fast? Netgate Global Support!

                            Do not Chat/PM for help!

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

                              I also had problems with ftp connections being very hit & miss since upgrading to 2.1. Setting this got it working again.

                              1 Reply Last reply Reply Quote 0
                              • A
                                athurdent
                                last edited by

                                I have setup a new pfSense VM on ESX 5.1 to debug this. I think I know what happened to my unresponisive ALIX test installation, pfSense just freezes after some time while trying to browse the FTP server stated some posts before. There's no error message, the console just freezes…
                                Any idea?

                                Edit: After 3 freezes while browsing the FTP my installation now crashed and rebooted. It collected the following attached crash report.

                                Edit2: I installed a fresh Snapshot from pfSense-LiveCD-2.1-RC0-amd64-20130701-1521.iso. I have tried everything but I was not able to freeze / crash it yet. Maybe the recent change to the FTP helper made pfSense somewhat unstable?

                                crash.txt

                                1 Reply Last reply Reply Quote 0
                                • L
                                  lucky
                                  last edited by

                                  I started having issues on around the May 9th snapshot. I didn't notice it until this past week because my FTP server isn't used much. Setting debug.pfftpproxy=1 has restored services, for now.

                                  My setup is fairly straightforward - three NICs, one WAN two LAN. The FTP server is in a VM that sits on one of the LAN segments. FTP server is a default Ubuntu wu-ftp daemon install. I have a NAT rule in place for FTP. I have traffic shaping, though FTP is not part of any special queue. That's about it. This has worked solidly until ~ May 9.

                                  Note - When I was initially troubleshooting, I noticed that the firewall was denying SYN ACKs going from the FTP server back to the client. The client failed to properly FTP data to my server in both active and passive mode.

                                  If I can provide anything else to help troubleshoot, please let me know and I'll get it for you.

                                  1 Reply Last reply Reply Quote 0
                                  • E
                                    eri--
                                    last edited by

                                    Wait for snapshots of tomorrow and test.

                                    1 Reply Last reply Reply Quote 0
                                    • A
                                      athurdent
                                      last edited by

                                      FTP did not get any better with the lastest snapshot Mon Jul 8 21:53:11 EDT 2013 . It should contain the newest fixes according to```
                                      cat /etc/version.lastcommit

                                      Half of the time passive FTP works, but I am still seeing those in the logs when the passive FTP session hangs.
                                      em0 is the LAN interface. My test system is single LAN/WAN.
                                      

                                      Jul  9 08:51:02 pfsense-ipv6 pf: 00:00:14.413456 rule 4/0(match): block out on em0: (tos 0x0, ttl 53, id 24551, offset 0, flags [DF], proto TCP (6), length 52)
                                      Jul  9 08:51:02 pfsense-ipv6 pf:     83.141.4.210.56941 > 192.168.x.x.56941: Flags [S.], cksum 0xa08a (correct), seq 1305586650, ack 72292906, win 5840, options [mss 1380,nop,nop,sackOK,nop,wscale 7], length 0

                                      So the state table still does not get updated correctly by the FTP proxy/helper.
                                      On the bright side, at least pfSense did not crash, yet.
                                      
                                      Edit:
                                      Active FTP does not work anymore, I'm getting those in the log:
                                      

                                      Jul  9 09:25:29 pfsense-ipv6 pf:    83.141.4.210.21 > 192.168.x.x.49686: Flags [P.], cksum 0x966e (correct), ack 212331008, win 5840, length 51
                                      Jul  9 09:25:29 pfsense-ipv6 pf: 00:00:00.212976 rule 4/0(match): block out on em0: (tos 0x0, ttl 53, id 9015, offset 0, flags [DF], proto TCP (6), length 91)
                                      Jul  9 09:25:29 pfsense-ipv6 pf:    83.141.4.210.21 > 192.168.x.x.49686: Flags [P.], cksum 0x966e (correct), ack 212331008, win 5840, length 51
                                      Jul  9 09:25:30 pfsense-ipv6 pf: 00:00:00.090747 rule 4/0(match): block out on em0: (tos 0x0, ttl 53, id 52027, offset 0, flags [DF], proto TCP (6), length 52)
                                      Jul  9 09:25:30 pfsense-ipv6 pf:    83.141.4.210.21 > 192.168.x.x.49686: Flags [.], cksum 0x1e4e (correct), ack 212331009, win 5840, options [nop,nop,sack 1 {212330981:212331009}], length 0
                                      Jul  9 09:25:30 pfsense-ipv6 pf: 00:00:00.335257 rule 4/0(match): block out on em0: (tos 0x0, ttl 53, id 23454, offset 0, flags [DF], proto TCP (6), length 91)
                                      Jul  9 09:25:30 pfsense-ipv6 pf:    83.141.4.210.21 > 192.168.x.x.49686: Flags [P.], cksum 0x966d (correct), ack 212331009, win 5840, length 51
                                      Jul  9 09:25:30 pfsense-ipv6 pf: 00:00:00.255013 rule 4/0(match): block out on em0: (tos 0x0, ttl 53, id 41021, offset 0, flags [DF], proto TCP (6), length 52)
                                      Jul  9 09:25:30 pfsense-ipv6 pf:    83.141.4.210.21 > 192.168.x.x.49686: Flags [.], cksum 0x1e4d (correct), ack 212331009, win 5840, options [nop,nop,sack 1 {212330981:212331010}], length 0
                                      Jul  9 09:25:31 pfsense-ipv6 pf: 00:00:00.597293 rule 4/0(match): block out on em0: (tos 0x0, ttl 53, id 24176, offset 0, flags [DF], proto TCP (6), length 91)
                                      Jul  9 09:25:31 pfsense-ipv6 pf:    83.141.4.210.21 > 192.168.x.x.49686: Flags [P.], cksum 0x966d (correct), ack 212331009, win 5840, length 51
                                      Jul  9 09:25:31 pfsense-ipv6 pf: 00:00:00.604381 rule 4/0(match): block out on em0: (tos 0x0, ttl 53, id 26446, offset 0, flags [DF], proto TCP (6), length 52)
                                      Jul  9 09:25:31 pfsense-ipv6 pf:    83.141.4.210.21 > 192.168.x.x.49686: Flags [.], cksum 0x1e4d (correct), ack 212331009, win 5840, options [nop,nop,sack 1 {212330981:212331010}], length 0
                                      Jul  9 09:25:32 pfsense-ipv6 pf: 00:00:01.101145 rule 4/0(match): block out on em0: (tos 0x0, ttl 53, id 11135, offset 0, flags [DF], proto TCP (6), length 91)
                                      Jul  9 09:25:32 pfsense-ipv6 pf:    83.141.4.210.21 > 192.168.x.x.49686: Flags [P.], cksum 0x966d (correct), ack 212331009, win 5840, length 51
                                      Jul  9 09:25:32 pfsense-ipv6 pf: 00:00:00.103532 rule 4/0(match): block out on em0: (tos 0x0, ttl 53, id 42482, offset 0, flags [DF], proto TCP (6), length 52)
                                      Jul  9 09:25:32 pfsense-ipv6 pf:    83.141.4.210.21 > 192.168.x.x.49686: Flags [.], cksum 0x1e4d (correct), ack 212331009, win 5840, options [nop,nop,sack 1 {212330981:212331010}], length 0
                                      Jul  9 09:25:34 pfsense-ipv6 pf: 00:00:01.204942 rule 4/0(match): block out on em0: (tos 0x0, ttl 53, id 64293, offset 0, flags [DF], proto TCP (6), length 52)
                                      Jul  9 09:25:34 pfsense-ipv6 pf:    83.141.4.210.21 > 192.168.x.x.49686: Flags [.], cksum 0x1e4d (correct), ack 212331009, win 5840, options [nop,nop,sack 1 {212330981:212331010}], length 0

                                      1 Reply Last reply Reply Quote 0
                                      • L
                                        lucky
                                        last edited by

                                        @ermal:

                                        Wait for snapshots of tomorrow and test.

                                        Still having the issue on: 2.1-RC0 (amd64) built on Tue Jul 9 23:33:36 EDT 2013

                                        Update: just to clarify, setting debug.pfftpproxy=1 still makes connections to my FTP server work again.

                                        1 Reply Last reply Reply Quote 0
                                        • D
                                          doktornotor Banned
                                          last edited by

                                          @lucky:

                                          Still having the issue on: 2.1-RC0 (amd64) built on Tue Jul 9 23:33:36 EDT 2013

                                          I had no issues before the latest patches. Broke more than it fixed.

                                          1 Reply Last reply Reply Quote 0
                                          • A
                                            athurdent
                                            last edited by

                                            My issues with FTP began after:
                                            https://redmine.pfsense.org/issues/2650#note-9
                                            Would be great if those patches could be reverted. FTP is sluggish/broken on both of my WAN lines now.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.