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

    [solved] Suricata resource consumption

    Scheduled Pinned Locked Moved IDS/IPS
    6 Posts 2 Posters 757 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.
    • Bob.DigB
      Bob.Dig LAYER 8
      last edited by Bob.Dig

      For me as a more novice user it is hard to see how many of the Firewall Maximum Table Entries are used and how my hardware utilization is at peaks.

      Now my question, will running Suricata on two interfaces almost double my resource consumption instead of running it only on one interface?
      And will running it on the parent interface of some VLANs reduce the resource consumption significantly instead of running it on each VLAN separate?

      I like to give every server its own VLAN but maybe I should change that for that reason.

      bmeeksB 1 Reply Last reply Reply Quote 0
      • bmeeksB
        bmeeks @Bob.Dig
        last edited by

        @Bob-Dig said in Suricata resource consumption:

        will running Suricata on two interfaces almost double my resource consumption instead of running it only on one interface?

        Potentially "yes", but it depends on the rules you enable on each Suricata instance. If you have the exact same rules, then the resource utilization in terms of RAM will pretty much double. CPU utilization may or may not because that will depend on the traffic flowing through each instance at any given time.

        @Bob-Dig said in Suricata resource consumption:

        will running it on the parent interface of some VLANs reduce the resource consumption significantly instead of running it on each VLAN separate?

        Yes. This is why running on the parent interface is suggested, especially when you would be running the same rule set on each VLAN instance. Another reason to use the parent interface is that Inline IPS Mode does not work properly when Suricata is running on a VLAN virtual interface. That's due to the way VLANs are created and plumbed in FreeBSD resulting in the netmap device not being provided all of the VLAN information.

        Bob.DigB 1 Reply Last reply Reply Quote 1
        • Bob.DigB
          Bob.Dig LAYER 8 @bmeeks
          last edited by

          @bmeeks said in Suricata resource consumption:

          Yes. This is why running on the parent interface is suggested, especially when you would be running the same rule set on each VLAN instance.

          Thanks Bill!

          I think I have read that with the new upcoming Suricata there will be changes to VLAN-handling? And if so, will the advice given still hold up then?

          bmeeksB 1 Reply Last reply Reply Quote 0
          • bmeeksB
            bmeeks @Bob.Dig
            last edited by bmeeks

            @Bob-Dig said in Suricata resource consumption:

            Thanks Bill!

            I think I have read that with the new upcoming Suricata there will be changes to VLAN-handling? And if so, will the advice given still hold up then?

            No, nothing inside Suricata matters in terms of VLANs and netmap and inline IPS mode operation. That is all within the FreeBSD operating system.

            There have been some recent additions to netmap in the FreeBSD tree, but I'm not sure which of those have made it into mainstream FreeBSD 14-CURRENT. I believe there are some changes that are still present only in the FreeBSD kernel used by OPNsense (they customize their FreeBSD kernel with some patches the same as pfSense does). It was OPNsense and Klara Systems that collaborated to create some netmap fixes for virtual adapters. VLAN, Bridge, and LAGG interfaces are types of virtual adapters where netmap had shortcomings. Some of the shortcomings have been fixed, but I believe currently it's only Bridge and LAGG virtual adapters that benefit. Per my understanding, it would require a pretty major operating system network stack change to enable netmap to natively process VLAN tags.

            The original creator of netmap did not design it to be used the way we are using it in the two "*Sense" firewall distros. It was designed to copy traffic just between two physical interface ports (for example, from em0 to em1). That mode would bypass the OS stack. But that mode of operation would be extremely wasteful of physical ports on a firewall as each interface (LAN, WAN, etc.) would require two separate physical NIC ports. So, we use the limited-feature host interface in netmap to send packets to and receive packets from the operating system network stack. That host stack interface is where the limitations come in.

            Bob.DigB 1 Reply Last reply Reply Quote 1
            • Bob.DigB
              Bob.Dig LAYER 8 @bmeeks
              last edited by Bob.Dig

              @bmeeks I run pfSense only on hyper-v and proxmox so I can use only legacy mode, at least I thought. It looks like vtnet is supported and proxmox is using that. Will try now.

              Bob.DigB 1 Reply Last reply Reply Quote 0
              • Bob.DigB
                Bob.Dig LAYER 8 @Bob.Dig
                last edited by

                @Bob-Dig said in [solved] Suricata resource consumption:

                It looks like vtnet is supported and proxmox is using that. Will try now.

                Had no luck with my weak VPS running pfSense in proxmox. I had random disconnects so I switched back to legacy mode.

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