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

    Pfsense NAT security

    Scheduled Pinned Locked Moved Firewalling
    17 Posts 4 Posters 23.4k 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.
    • A
      AudiAddict
      last edited by

      @billm:

      The last poster was incorrect.  You are accepting the traffic and creating state on it.  The firewall then has nowhere to send it, so those connections sit in the state table until timeout (about 5 seconds for embryonic connections I think, might be 45, can't recall the default).  The packet filter works just fine without NAT as you've noticed, keep that in mind going forward.

      Ok, that makes it more clear to me and that's why it's obviously being logged in my traffic logs with the syslogger.

      Since it is filling up the actual tables with this information/connection even though it has no destination it would be better to drop or block these packets.

      Because if I were to scan/connect to 2500 ports on a complete ip range(with hosts), 2500 states are created even though they don't do anything.

      Would it be possible to make a rule for this " issue"? I haven't found the timeout option for these either.

      That's how pflogd logs it.  We haven't touched that code.

      Could I alter this by any chance? Is this easy to do? I created a bounty for this but nobody replied.

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

        @GruensFroeschli:

        @billm:

        The last poster was incorrect.  You are accepting the traffic and creating state on it.  The firewall then has nowhere to send it, so those connections sit in the state table until timeout (about 5 seconds for embryonic connections I think, might be 45, can't recall the default).  The packet filter works just fine without NAT as you've noticed, keep that in mind going forward.

        Hmm.
        Could you explain that a bit more indepth?
        I kind of remember reading multiple times that NAT is being applied before the firewall-rules.
        Like here: http://forum.pfsense.org/index.php/topic,1903.msg10976/topicseen.html#msg10976

        Sure.

        Inbound packet path to the kernel

        NAT -> Filter -> kernel

        Outbound packet path from the kernel

        kernel -> NAT -> Filter

        If you don't have a NAT entry that matches a packet, it'll still get to the filter.  But for the purpose of filtering NAT'd connections, you need to understand that the filter is applied AFTER NAT, therefore a connection to a virtual address on the outside of your firewall will get NAT'd first, so the filter policy has to match the post NAT packet.  Primarily, it's just important to know the order of the actions being applied to your traffic.

        –Bill

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

        1 Reply Last reply Reply Quote 0
        • GruensFroeschliG
          GruensFroeschli
          last edited by

          Makes sense :)
          Thank you for the explanation.

          We do what we must, because we can.

          Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

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

            Thanks for the info!

            Unfort, the main issue I'm having now is that I can easiliy " kill " or ddos my pfsense with two Nnmap scans on a single public ip (not even selecting our whole public ip block).

            The cpu usage stays at 2procent max.. throughput is only 1/2mb/sec and our wan is being used for 500kb/sec.

            We have a 100mbit wan (fiber) and a 2GB/P43ghz machine.. so the hardware isn't the problem.

            With further research, the whole problem right now is that the states fill up really fast (it seems each tcp port it scans with Nnap) get's a seperate entry in the table.

            Let's say I scan 5000 tcp ports, twice with the port scan utilities on the internet.. the state tables are full :(

            See images..(scan done at aprox 18.00hrs)

            States..

            Cpu usage..it's doing nothing…

            States..in zabbix (our monitoring software)

            Wan traffic (only 70/80kb/sec being recieved..so not the wan connection)

            And bang.. the firewall stops taking other traffic/connections and thus causing a non working network..even our website is unreachable or really slow.

            So anybody could annoy us by running Nmap, Nessus or an online port scanner and set it to scan 5000 ports or more.. and cause us to go down.. Major issue for us :(.

            Now I could simply add another zero to the max states.. but I dont' think that would be a very good/safe idea..

            To me this looks like a major feature request or maybe even a bug if you can't fix this? (correct me if I'm wrong).

            If the firewall gives out one entry in the state table for each port which is scanned from the outside world, the firewall easily slows down.. or becomes unreachable..

            Anybody have an idea on how to solve/prevent this without increasing the amount of states? In other words.. wouldn't it be so much better to drop packets instantly if they have no NAT rule set up?

            1 Reply Last reply Reply Quote 0
            • jahonixJ
              jahonix
              last edited by

              The 'Advanced Options' tab at 'Firewall: Rules: Edit' hides some useful stuff for this.
              You can alter:

              • Simultaneous client connection limit
              • Maximum state entries per host
              • Maximum new connections / per second
              • State Timeout in seconds
                there.

              That should solve this problem for you.

              1 Reply Last reply Reply Quote 0
              • GruensFroeschliG
                GruensFroeschli
                last edited by

                Combined with what jahonix posted you can safely increase the statetable-size.

                @http://www.pfsense.org/index.php?option=com_content&task=view&id=52&Itemid=49:

                Large state tables - State table entries require about 1 KB of RAM each.  The default state table, when full at 10,000 entries, takes up a little less than 10 MB RAM. For large environments requiring state tables with hundreds of thousands of connections, ensure adequate RAM is available.

                It's not a problem to increase the statetable.
                Just make sure you dont run out of ram.

                We do what we must, because we can.

                Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

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

                  @jahonix:

                  The 'Advanced Options' tab at 'Firewall: Rules: Edit' hides some useful stuff for this.
                  You can alter:

                  • Simultaneous client connection limit
                  • Maximum state entries per host
                  • Maximum new connections / per second
                  • State Timeout in seconds
                    there.

                  That should solve this problem for you.

                  Thanks, didn't know this, but will this have any effect if NAT gets done first (and that's where the states max out with..)?

                  If these options are the answer to the problem, what options(amount/setting) do you suggest I use?

                  Also, maybe a stupid question.. let's say I use one of the settings..if I leave the rest blank.. it stays on the defaults I suppose?

                  @GruensFroeschli:

                  Combined with what jahonix posted you can safely increase the statetable-size.

                  @http://www.pfsense.org/index.php?option=com_content&task=view&id=52&Itemid=49:

                  Large state tables - State table entries require about 1 KB of RAM each.  The default state table, when full at 10,000 entries, takes up a little less than 10 MB RAM. For large environments requiring state tables with hundreds of thousands of connections, ensure adequate RAM is available.

                  It's not a problem to increase the statetable.
                  Just make sure you dont run out of ram.

                  Although we have plenty of ram.. I'm still worried about the fact, doing a portscan on our ip block (50 public ip's) and scanning 5000 ports for each public ip would be 50x5000 states..=firewall overload..

                  The settings in the rules are useless if they are not used since the rules ares effected AFTER the NATing..

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

                    @AudiAddict:

                    @jahonix:

                    The 'Advanced Options' tab at 'Firewall: Rules: Edit' hides some useful stuff for this.
                    You can alter:

                    • Simultaneous client connection limit
                    • Maximum state entries per host
                    • Maximum new connections / per second
                    • State Timeout in seconds
                      there.

                    That should solve this problem for you.

                    Thanks, didn't know this, but will this have any effect if NAT gets done first (and that's where the states max out with..)?

                    Generically, a state gets created for the NAT (no state for you right now) and a state gets created for the filter.

                    @AudiAddict:

                    Although we have plenty of ram.. I'm still worried about the fact, doing a portscan on our ip block (50 public ip's) and scanning 5000 ports for each public ip would be 50x5000 states..=firewall overload..

                    The settings in the rules are useless if they are not used since the rules ares effected AFTER the NATing..

                    In your case you are allowing the traffic and generating state.  We're a little more dynamic in the default state table size in 1.3 - I don't remember the formula offhand, but it scales with memory (I think it's 10% of ram).  One thing you can do in your rule is limit the number of states a given address can use - just set the "Maximum state entries per host" variable in your "allow all" rule that you have on the wan to something "reasonable" (I'll leave it to you to determine what "reasonable" is).  That will effectively restrict the amount of damage an nmap scan can do.

                    –Bill

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

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

                      So Maximum state entries per host option is sufficient?

                      Can I leave the other fields blank?

                      Regarding the amount, could you give me a suggestion on what to use? I don't want to limit any services running on our wan side.. what would be a reasonable amount?

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

                        @AudiAddict:

                        So Maximum state entries per host option is sufficient?

                        Can I leave the other fields blank?

                        Regarding the amount, could you give me a suggestion on what to use? I don't want to limit any services running on our wan side.. what would be a reasonable amount?

                        Correct on the first two questions.  The last really is site specific.  It could be two, it could be a hundred, it could be more shrug.  That's why I said, whatever is reasonable for you.  I don't know what type of traffic you see.

                        –Bill

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

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