• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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 Aug 20, 2008, 9:18 AM

    @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 Aug 20, 2008, 3:27 PM

      @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
      • G
        GruensFroeschli
        last edited by Aug 20, 2008, 3:30 PM

        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 Aug 20, 2008, 5:02 PM Aug 20, 2008, 4:46 PM

          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
          • J
            jahonix
            last edited by Aug 20, 2008, 5:02 PM

            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
            • G
              GruensFroeschli
              last edited by Aug 20, 2008, 5:25 PM

              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 Aug 20, 2008, 5:29 PM

                @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 Aug 20, 2008, 5:40 PM

                  @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 Aug 20, 2008, 6:55 PM

                    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 Aug 20, 2008, 9:03 PM

                      @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
                      17 out of 17
                      • First post
                        17/17
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                        This community forum collects and processes your personal information.
                        consent.not_received