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

    NAT Reflection (timeout problem)

    Scheduled Pinned Locked Moved NAT
    30 Posts 7 Posters 17.8k 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.
    • D
      Dhauzimmer
      last edited by

      Hi all,

      Not sure if anyone's still following this, but I ran in to this problem myself.  I installed pfSense yesterday, rigged 'er up for my network, and then found that my jabber server was dropping and reconnecting every few minutes.  I tried the fixes recommended here with no success, so I started digging about to find out how NAT reflection is implemented and configured under the hood.

      As it turns out, the netcat sessions used for NAT reflection are spawned with a 20-second idle timeout which is not configurable.  Of course, using a higher timeout means a greater likelihood of dead netcat sessions kicking about on one's firewall, so I'm not convinced that simply tweaking this value is the right answer here.

      I'll post back later after I've had a bit longer to play with it - there's got to be a better way of implementing NAT reflection!

      -Dhauzimmer

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

        We followed the standard way:

        http://www.openbsd.org/faq/pf/rdr.html

        But by all means, feel free to make a better solution!

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

          Thanks for the link - invaluable information for a BSD newbie.  :)

          I've cobbled together a solution that is based around the fourth ("not recommended") pattern - it uses tagging to ensure that only relevant packets get mangled by the return NAT rule.  Before I pass it along, though, a quick question:  This solution will use two 'states' instead of running TCP proxy daemons.  Will that consume more CPU/memory/other resources?

          I also haven't fully cleaned out all the spawn-inetd stuff, nor have I thoroughly tested the fix for all possible cases.  I did a bit of cleanup on the surrounding code, though, and added a clause to suppress issuing redirect rules for interfaces that are currently disabled.  There may also be some cross-interface issues if you've got optional interfaces involved; I didn't do a thorough analysis of all the possible permutations.  However, it has the up side that it will properly handle large port ranges at no extra charge.

          If you're interested, where would I go to submit a patch?

          -D

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

            Patches and the format can be found here http://wiki.pfsense.com/wikka.php?wakka=SubmittingPatches

            We  absolutely appreciate patches.

            Thanks!

            1 Reply Last reply Reply Quote 0
            • N
              n6mod
              last edited by

              This timeout issue is causing me a lot of heartache as well.

              I've just replaced a WRT54G running DD-WRT with a pfsense box (VLAN-based one-armed router) and everybody is complaining about ssh timeouts and the like. 20s is way too short.

              In my case, making that timeout an hour wouldn't hurt much, since there are about four forwards on the box, and I can't see more than a few connections to each. Certainly consuming two states is a non-issue.

              I really like the other features of pfSense, but unfortunately this could be a dealbreaker for us.

              -Zandr

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

                @n6mod:

                This timeout issue is causing me a lot of heartache as well.

                I've just replaced a WRT54G running DD-WRT with a pfsense box (VLAN-based one-armed router) and everybody is complaining about ssh timeouts and the like. 20s is way too short.

                In my case, making that timeout an hour wouldn't hurt much, since there are about four forwards on the box, and I can't see more than a few connections to each. Certainly consuming two states is a non-issue.

                I really like the other features of pfSense, but unfortunately this could be a dealbreaker for us.

                -Zandr

                Maybe turn on SSH keep-alives?  Putty supports it and so does ssh.

                1 Reply Last reply Reply Quote 0
                • N
                  n6mod
                  last edited by

                  @sullrich:

                  Maybe turn on SSH keep-alives?  Putty supports it and so does ssh.

                  That takes care of SSH, and we've done that, but we have other applications (our software) that expect idle connections to last more than a few seconds.

                  Even just making that configurable would be a huge help.

                  -Z

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

                    Okay, I added a hidden option for controlling this.

                    edit config.xml by downloading it via the webConfigurator backup feature.

                    add a <reflectiontimeout>100</reflectiontimeout> area to <system>So it should end up looking something like:

                    <system><reflectiontimeout>100</reflectiontimeout>

                    Upload the changed config.xml … The firewall will reboot.

                    This will show up in about 2 hours after the snapshot server rebuilds the images.</system></system>

                    1 Reply Last reply Reply Quote 0
                    • N
                      n6mod
                      last edited by

                      Outstanding. I'll grab a new image in the morning. Thanks for the super-fast response.

                      -Zandr

                      1 Reply Last reply Reply Quote 0
                      • F
                        firbc
                        last edited by

                        Very nice this thing also works for me. Will be this features also integrated into GUI?

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

                          @firbc:

                          Very nice this thing also works for me. Will be this features also integrated into GUI?

                          Doubtful.

                          1 Reply Last reply Reply Quote 0
                          • N
                            n6mod
                            last edited by

                            I never followed up here… This is working great. I set it to 3600s (1hr) and all of the issues with our other apps have gone away.

                            We only have a few forwards anyway, so I'm not too concerned about the resources consumed by those nc's.

                            I'd second the suggestion to tuck this into the GUI somewhere, it's a pretty useful feature. Though, if it were superseded by Dhauzimmer's patch, that could be even better.

                            Thanks again.

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

                              Will consider the GUI option after I pass it by other devs.

                              The patch was submitted to coreteam but had the potential to break QOS and Multi-Wan so it is not quite ready yet.  This is going from memory..  I am terribly sorry if I am confusing two different incidents.

                              1 Reply Last reply Reply Quote 0
                              • B
                                billm
                                last edited by

                                @sullrich:

                                Will consider the GUI option after I pass it by other devs.

                                The patch was submitted to coreteam but had the potential to break QOS and Multi-Wan so it is not quite ready yet.  This is going from memory..  I am terribly sorry if I am confusing two different incidents.

                                Why not just default it to 1 hour?  I'd rather not see yet another knob that people will twist for no good reason exposed.

                                –Bill

                                pfSense core developer
                                blog - http://www.ucsecurity.com/
                                twitter - billmarquette

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

                                  I am perfectly fine with this as long as no DOS potential is present?

                                  1 Reply Last reply Reply Quote 0
                                  • F
                                    firbc
                                    last edited by

                                    Question

                                    I see in blogspot that you change NAT reflection timeout to 2000 by default, so I decide to remove line <reflectiontimeout>2000</reflectiontimeout> (work with this line) from config.xml. I reboot my server machine and try connecting to battle.net (the way I testing nat reflection timeout) with 2 users on LAN.  After 20s LAN user joined in game has been disconnected.

                                    So question, am I need to install fresh copy of pfsense or is this normally and I just put those line back to config.xml?

                                    I using last version of pfsense 1.2 RC2 18.8.2007

                                    Thx

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

                                      You cannot simply remove the line.  It needs a value.

                                      1 Reply Last reply Reply Quote 0
                                      • F
                                        firbc
                                        last edited by

                                        As far as I see this line is optional and only change default value to value that you want. So I thought that now when default is 2000s line in config.xlm for reflection time out isn’t needed any more. Am I wrong?

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

                                          Yes, that is wrong.  If you do not want a timeout, set it to 0.

                                          1 Reply Last reply Reply Quote 0
                                          • F
                                            firbc
                                            last edited by

                                            Ok and what is default timeout if there is no line in config.xml? I asking because you add that options in past »I added a hidden option for controlling this«.

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