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

    Port foward reflection problem

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    27 Posts 6 Posters 9.7k Views
    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.
    • E
      Elv13
      last edited by

      Hi,

      I installed pfsense last week and I am having problem with my port foward. I was not sure why it was not working, but now I understand that it is disabled by pfsense when you try to access them from inside of my network. That's fine, I understand why it work like that, but it is not an option for me. My laptop share many svn repository and I want to be able to commit from the outside too, so I can't just use the internal IP.

      When I uncheck "disable reflection" in System;advanced;firewall, it get this when I try to access a web page (websvn) on our server:

      usage: nc [-46DEdhklnrStUuvz] [-e policy] [-i interval] [-P proxy_username] [-p source_port]
      	  [-s source_ip_address] [-T ToS] [-w timeout] [-X proxy_protocol]
      	  [-x proxy_address[:port]] [hostname] [port[s]]
      
      

      When I use a proxy it work just fine (but for security concern, it is not an option). Other fowarded services don't work too, such as ssh. How can I solve that?

      1 Reply Last reply Reply Quote 0
      • R
        Runefox
        last edited by

        I don't mean to thread necro, here, but this is still an issue.

        I've grabbed the latest snapshot (20091220-2310) and the issue still remains. I've run into this as well, and I've been looking around the forums for information. After reading about some issues present in some older versions of it (those older fixes already applied in this release), I dove into the /etc/inc/filter.inc file and found a few lines starting at line 753:

        $reflection_txt = "\tstream\ttcp/udp\tnowait/0\tnobody\t/usr/bin/nc nc -w {$reflectiontimeout}{$target} {$tda}\n";
        

        It seems like the nc command was typed twice by mistake, and it's like this for every occurrence of the nc command (there are two more; On lines 760, 785). Modifying the line to read:

        $reflection_txt = "\tstream\ttcp/udp\tnowait/0\tnobody\t/usr/bin/nc -w {$reflectiontimeout}{$target} {$tda}\n";
        

        Causes the nc message to disappear, but I'm still looking into fixing it - It still doesn't redirect properly to the LAN host; Instead, it's redirecting to the firewall's localhost. I'm not terribly well-versed in pfSense's codebase nor coding in general (more of a hacker), so maybe someone else could take what I've found and turn it into something a little more helpful.

        EDIT: Upon closer inspection, it looks as though $target doesn't properly address the LAN host (it comes up blank in inetd.conf). It also seems to be nuking every other reflection-related line once it reaches the final port reflection rule, leaving only the last in the listing present in inetd.conf.

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

          try next snap.

          1 Reply Last reply Reply Quote 0
          • R
            Runefox
            last edited by

            Newest snapshot (20091222-1721) seems to remedy the issue with redirecting to localhost, but still deletes all reflection rules but the last in the list from inetd.conf (thus meaning only the last rule in the list will be reflected) and in addition causes the filter (re)load to break altogether with ranges of ports, regardless of NAT reflection being enabled or disabled. The error according to the Filter Reload page is:

            Syntax error in config file: pf rules not loaded - The line in question reads [78]: rdr pass on fxp0 proto { tcp udp } from any to (Ext. IP Hidden) port 7840-7850 -> (Int. IP hidden) port 7840…

            I should add that deleting/recreating the rule or creating a new rule with any port range other than a single port causes the issue, as well.

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

              Can you please send /tmp/rules.debug and /etc/inetd.conf and your config.xml.
              Even privately if you are concerned.

              1 Reply Last reply Reply Quote 0
              • R
                Runefox
                last edited by

                I PM'ed the contents of the files in question. I did end up having to remove the port ranges in order to actually get my internet connection to work from within the LAN, so I added one of the ranges I did use before for demonstration purposes. It still causes a filter load error.

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

                  https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/d9e258bb1df4c8a0d720c818ad433f8e9f6c3824

                  Here is the fix.

                  1 Reply Last reply Reply Quote 0
                  • R
                    Runefox
                    last edited by

                    Thanks, I can confirm that adding those lines did fix the filter load problem with port ranges. The only issue that remains now is that only the last of the NAT rules is kept in inetd.conf for reflection, rather than the entire table (as you can see with the inetd.conf I sent you as compared to the port ranges specified in the reflection rules). It appears that once the list is generated, it deletes all but the final NAT entry.

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

                      https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/34fd61683d5ddaf531a0db916f4d7d5d1e07d54c

                      :)

                      1 Reply Last reply Reply Quote 0
                      • R
                        Runefox
                        last edited by

                        I applied the diff to filter.inc and modified the NAT table to test it out. It doesn't cause any errors on reload or anything, but it doesn't actually write anything out to the inetd.conf file (it remains empty but for the tftp-proxy line) and the redirects end up not working. It's worth noting that I haven't yet upgraded from snapshot 20091222-1721, so I am working from that version of the /etc/inc/filter.inc file.

                        1 Reply Last reply Reply Quote 0
                        • R
                          Runefox
                          last edited by

                          Sorry to double-post, but I've updated to the latest snapshot (20091224-0722) and the problem persists - The inetd.conf file isn't being properly written to, either not being populated at all, or being populated and then having all the entries removed. NAT reflection is enabled, and I've tried changing the NAT table to force a reload with no success. As far as I can tell, this is probably the last hurdle to getting NAT reflection working again.

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

                            I also had this problem and here is how i fixed it, I'm not a coder (more sysadmin) so it kinda hack, but it should help the devs fix the problem and provide a solution for anyone who wants it. I had to make a few changes to /etc/inc/filter.inc

                            Starting around line 803

                            
                                                                            $reflection_txt[] = "{$inetdport}\tstream\ttcp\tnowait/0\tnobody\t/usr/bin/nc nc -w {$reflectiontimeout} {$target} {$tda}\n";
                                                                            $reflection_txt[] = "{$inetdport}\tdgram\tudp\tnowait/0\tnobody\t/usr/bin/nc nc -u -w {$reflectiontimeout} {$target} {$tda}\n";
                            
                            

                            And alittle more down

                            
                            $reflection_txt[] = "{$inetdport}\t{$socktype}\t{$protocol}\tnowait/0\tnobody\t/usr/bin/nc nc {$dash_u}-w {$reflectiontimeout} {$target} {$tda}\n";
                            
                            

                            You need to add a second nc in there, i got it from here http://www.openbsd.org/faq/pf/rdr.html

                            Next a few lines down you need to update:

                            
                                            $inetd_fd = fopen("/var/etc/inetd.conf","a");
                            
                                            /* add tftp protocol helper */
                                            /* fwrite($inetd_fd, "tftp\tdgram\tudp\twait\t\troot\t/usr/local/sbin/tftp-proxy -v\n"); */
                                            $reflection_txt = array_unique($reflection_txt);
                                            foreach ($reflection_txt as $txtline)
                                                    fwrite($inetd_fd, $txtline);
                                            fclose($inetd_fd);
                            
                            

                            The big there was changing the "w" to "a" (the a tells it start at the end of the file, not the top). I commented out the tftp-proxy part, as this should be moved outside the loops somewhere, but I'm not using it so instead finding the right place, I just commented it out.

                            Last change is around line 1166

                            
                                                    $natrules .= filter_generate_reflection($rule, $target, $extport, $starting_localhost_port);
                                                    $natrules .= "\n";
                                                    $starting_localhost_port++;
                            
                            

                            You need to add the  "$starting_localhost_port++;". I could not find anywhere that was being incremented so every new rule was always using port 19000

                            1 Reply Last reply Reply Quote 0
                            • P
                              puithove
                              last edited by

                              I just wanted to chime in here and mention that I'm affected by this issue.  I run a web access portal behind my firewall via NAT port forwarding.  Need to be able to use the same URL whether inside or outside my home network but the NAT reflection is not working.  Worked fine under 1.2.3 - does not work with "2.0-BETA1
                              built on Fri Jan 8 03:48:57 EST 2010
                              FreeBSD 8.0-RELEASE-p2"

                              Edit:  Thought it might be useful to point out that this was an in-place upgrade from 1.2.3

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

                                I made some changes lately so try newer snapshots.

                                1 Reply Last reply Reply Quote 0
                                • R
                                  Runefox
                                  last edited by

                                  The latest snapshot (20100108-0349) has the same problem as previous - The NAT reflection rules are not created properly, and only the last NAT rule is listed. I can confirm that casshan's fix did actually solve the problem and that NAT reflection is fully working on my setup with those modifications. Many thanks, casshan! Maybe someone can clean it up to work with the tftp proxy so it can finally be deployed and fixed with future snapshots.

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

                                    That is an old snapshot actually.

                                    https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/01cf3e74e5c1fae3c47c0e0154a0f1bd0964d986
                                    This are the changes.

                                    1 Reply Last reply Reply Quote 0
                                    • R
                                      Runefox
                                      last edited by

                                      That's an old snapshot? It was (and is) the most recent available in the i386 repo. Are updates still being made at http://snapshots.pfsense.org/FreeBSD_RELENG_8_0/i386/pfSense_HEAD/updates/ or is there another place to receive updates now?

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

                                        The snapshot server is having some hardware issues and may not have been building new snaps. Last I heard they were waiting on FedEx to deliver the new server to replace it. I imagine it will have to undergo some configuration and testing before moving to the data center to replace the failed server.

                                        The snapshots URL is actually pointing to a mirror site right now and not the server.

                                        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
                                        • P
                                          puithove
                                          last edited by

                                          I just upgraded to "2.0-BETA1 built on Fri Jan 22 00:26:29 EST 2010" and am still having the issue.  After the upgrade I deleted a port-forward rule and recreated it with linked filter rule but it's still having the same issue.

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

                                            Can you detail what issues?

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