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

    Debian + Shorewall vs pfSense

    Scheduled Pinned Locked Moved General pfSense Questions
    5 Posts 3 Posters 9.0k 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
      arduino
      last edited by

      I know I am likely missing something, but I am wondering why pfSense routing speed is low compared to a my Debian system?

      I've tried several different hardware setups and the Debian system always performs better. I am able to route 10GB on my Pentium G3220 Debian system regardless of size of rule set, yet pfSense on the same hardware can't go beyond 1.4GB/s.

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

        Linux with multiple cores is about 35% faster (higher top end throughput on a given piece of hardware) than FreeBSD pf on equivalent hardware, so some difference is attributable to that.

        discussion of performance comparison here, roughly around the time that's marked in the link:
        https://youtu.be/LE4wMsP7zeA

        If you're seeing 1.4 Gb vs. 10 Gb (unclear whether you mean bits or Bytes, guessing should be lower case b bits in your post), there is something else causing the difference. Maybe your Linux config isn't actually comparable (1 rule vs. 100 in pf, or not routing or NATing or something in a comparable way), or what you're measuring isn't the same or isn't relevant, or maybe you have a combination of hardware that doesn't play nicely with FreeBSD.

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

          Yes I meant giga_bit_, sorry.

          I've done tests with both being baseline installs (no extra rules, besides allowing iperf and other testing software)

          Tried six different single/dual and quad port Intel nic's. I've also tried Supermicro, Tyan and Intel server boards but nothing changes, anything above 600Mb/s shows very high CPU.

          My G3220 shows 0.4% CPU usage @ 1.4Gb/s and pfSense on the same hardware is 100%. Even pfSense with a 6 core HT E5-2620 can't keep up with the dual core G3220 on my Debian system.

          The tests have been done and the consensus I get is I have done something wrong, but this does seem strange.

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

            Is that to the box, or through the box? Routing, NAT, bridging, or?

            The numbers you're getting with Linux with such extremely low CPU usage make it seem likely the firewall isn't enabled at all.

            1 Reply Last reply Reply Quote 0
            • ?
              Guest
              last edited by

              I know I am likely missing something, but I am wondering why pfSense routing speed is low compared to a my Debian system?

              Linux and FreeBSD are not the same OS as many peoples would imagine. And they are often not really comparable
              in what discipline ever you want. Linux is more smooth and liquid running and more agile function. BSD based
              systems are more stable and on the right hardware also smooth and liquid running, but often a little bit tuning
              is needed. pfSense is not a set up and forget it solution as many users might expecting.

              I've tried several different hardware setups and the Debian system always performs better.

              It is an open secret that the Linux systems are often better recognized by the hardware vendors and on top
              much better sorted with drivers. BSD system are mostly not so good sorted with drivers by the vendors and
              there fore you might be more comparing BSD against BSD based systems and Linux against Linux based
              systems, to come closer to the point you want.

              I am able to route 10GB on my Pentium G3220 Debian system regardless of size of rule set,

              WAN - LAN or what routing we are talking here from? Debian is using all CPU cores and FreeBSD where pfSense
              is based on is only using one CPU core at the WAN Port using PPPoE. So what?

              yet pfSense on the same hardware can't go beyond 1.4GB/s.

              Please read the line above.

              My G3220 shows 0.4% CPU usage @ 1.4Gb/s and pfSense on the same hardware is 100%.

              pfSense is only using one CPU core at the WAN Port and your Linux is using all cores.

              Even pfSense with a 6 core HT E5-2620 can't keep up with the dual core G3220 on my Debian system.

              I am using an Intel E3-1285v3 @3,5GHz and all is running like hell, 2 x 200 MBit/s at the WAN side and
              10 GBit/s to the DMZ and LAN Switch. All is smooth and liquid running for me. Did you thew following?

              • Enable TRIM support for mSATA or SSDs
              • Enable PowerD (hi adaptive)
              • High up the mbuf sizes

              This is what I was talking above from, in pfSense you are able to tune or fine tune many things that
              your system will more running likes you want and with Linux this might be not even the time.

              How your test was running? From where to where?

              • 1 PC on the LAN side (192.xx.xx.)
              • 1 PC on the WAN side (172.xx.xx)
                Using iperf -a -p

              So you might be able to see also pfSense is able to route all the things to route likes other systems are doing.
              Debian is not a hardened Linux OS, so I would be aware of using it likes a firewall! CentOS came from house
              hardened and might be a better choice for that or perhaps taking ClearOS might be a good choice for this
              action.

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