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

    Dns traffic blocked heavy load

    Scheduled Pinned Locked Moved Firewalling
    7 Posts 3 Posters 3.6k 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.
    • W
      wizard
      last edited by

      I am using pfsense as a firewall for our dns servers. At the moment i am migrating all our dns servers from windows bind to linux powerdns. Uptill now everything is working fine i have two important rules in the firewall one for icmp (ping) to the dns servers. And one for the udp/tcp traffic to port 53 on the dns servers. I migrated the low traffic dns servers two weeks ago and the setup seemed to work. So i thought i would try a few of the servers with heavy traffic about 3000 queries a minute. Once i migrate one of these servers the pfsense box starts blocking traffic after about 10-15 minutes when the load gets high. Is there a burst limit set somewhere? Or anything else i should look into. I tested the same setup behind a linux firewall and everything continued to work fine. I don't really like the idea of changing the pfsense box for a linux box i would prefer to find the issue perhaps someone can help. I am willing to provide more information if nessary.

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

        I bet your running out of states.

        Increase the state count in system -> advanced and also set the optimization to aggressive.

        1 Reply Last reply Reply Quote 0
        • H
          hoba
          last edited by

          You also can add a short statetimeout for the firewallrules concerning the DNS traffic. You don't need 24h for them, dns requests are only short queries. Set it to 5 minutes or something smaller. You'll find these settings hding below one of the advanced buttons when you edit a firewallrule.

          1 Reply Last reply Reply Quote 0
          • W
            wizard
            last edited by

            Increase the state count in system -> advanced and also set the optimization to aggressive.

            i've already done that i don't think states are the problem as the max states entry was never reached. Would it be worth trying to switch to bridge mode?

            1 Reply Last reply Reply Quote 0
            • W
              wizard
              last edited by

              I think i found the culprit i switched of device polling and changed the statetimeout to 240 seconds. Since then all my tests under heavy traffic have been successful i am pleased with the results. Because i really want to stick with pfsense with this results it should be easy to convince my boss.

              thanks for your help

              regards wizard

              1 Reply Last reply Reply Quote 0
              • H
                hoba
                last edited by

                Device polling is not very optimized yet and won't have the best performance. See http://wiki.pfsense.com/wikka.php?wakka=Tuning for some values that we did test out with a wrap. Other (bigger) systems of course need different values. Maybe we'll have some optimizations or some way of customizations for this mode in the next version. For now I recommend to not use device polling.

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

                  If you are running polling then the share of userland vs kerneland needs to be altered.

                  On a really busy dns server that would mean that the split between kernel workload and userland workload needs to be about 50/50.

                  I cannot recall what our defaults are but I would suggest as hoba did to not run polling unless you spend quite a bit of time "tunning" it for your workload.

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