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

    Snort blocks WAN IP….!

    Scheduled Pinned Locked Moved pfSense Packages
    20 Posts 2 Posters 11.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.
    • S
      Supermule Banned
      last edited by

      I have both edited the Friendly_ip whitelist to include the IP range /26 but it doesnt get updated in the Snort code.

      Other ranges are there no problem.

      Update: I updated the friendlyip list manually and put in the range. Restarted Snort and it didnt give errors.

      But there is definately something wrong in PFSense regarding this package and the way it is controlled by the GUI.

      If I edit the friendlyIP alias in PfSense, then it doesnt update the list in Snort even though its an alias.

      1 Reply Last reply Reply Quote 0
      • bmeeksB
        bmeeks
        last edited by

        Did the new IP Range Alias show up in the Whitelist tab properly in the GUI after entering it via the GUI?  Trying to establish if the code might be having a problem with the slash during the PHP post/get operations (maybe not properly URL-encoding the slash).

        1 Reply Last reply Reply Quote 0
        • S
          Supermule Banned
          last edited by

          I edited an allready existing alias….and put it in there.

          It has 3 IP ranges in there allready with /....

          1 Reply Last reply Reply Quote 0
          • S
            Supermule Banned
            last edited by

            Still blocks the WAN IP….............!!

            1 Reply Last reply Reply Quote 0
            • bmeeksB
              bmeeks
              last edited by

              Possibly dumb question, but is the WAN VIP in the same subnet as the actual WAN IP of the box?  It might be the "snort2c" and "pfctl" modules that are getting confused and not Snort directly.  In pfSense the actual blocking by Snort is done by a third-party plug-in patched into the Snort code.  That plug-in might be where the problem is, and if so, will be much harder to troubleshoot.

              Bill

              1 Reply Last reply Reply Quote 0
              • S
                Supermule Banned
                last edited by

                yes it is :) All part of the same range.

                1 Reply Last reply Reply Quote 0
                • bmeeksB
                  bmeeks
                  last edited by

                  The last troubleshooting step to hopefully isolate the culprit:

                  If the whitelist file referenced in the snort.conf file for the interface on the "output alert_pf" line actually contains a properly constructed setting for your virtual IP, then in my view that narrows the problem down to the third-party plugin and not really with Snort itself.  The values in that file are pulled out and compared to "offending" IP addresses, and if there is a match, then the offender IP is NOT put in the blocking table.

                  Someone with a lot more knowledge of the packet filtering engine in FreeBSD may have to take it from there.

                  EDIT:  just one last clarifying question (I apologize if you have answered this previously) – is Snort blocking the WAN VIP, the WAN interface IP, or both?

                  Bill

                  1 Reply Last reply Reply Quote 0
                  • S
                    Supermule Banned
                    last edited by

                    Only WAN VIP. NOT the interface IP.

                    1 Reply Last reply Reply Quote 0
                    • bmeeksB
                      bmeeks
                      last edited by

                      I am kind of leaning toward this being a problem with the snort2c plug-in that actually puts the temp rule in the packet filter engine.  But as I've said a few times, I am not the subject-matter expert in this area.

                      Maybe one of the core pfSense developers can chime in here with an idea.

                      A general call out to the public using Snort on pfSense:
                      Does anyone else out there using virtual IPs in pfSense with Snort in blocking mode have a problem with Snort blocking the WAN virtual IP?

                      Bill

                      1 Reply Last reply Reply Quote 0
                      • S
                        Supermule Banned
                        last edited by

                        Update: It blocks WAN interface IP as well. But that happened only after the addition of the /26 range in Snort including the /

                        When Alias is edited and /26 range is removed, SNORT DOESNT GET UPDATED in the txt file in /usr/local/snort/interfacexxx/

                        So there is definately a bug in the system!

                        1 Reply Last reply Reply Quote 0
                        • bmeeksB
                          bmeeks
                          last edited by

                          I guess I need to setup a dual-firewall system in VMware Workstation with pfSense to play around with this.  However, I've never set up CARP with pfSense.  I have configure VRRP in Check Point firewalls, though.  Should be similar in concept, just not identical in form and procedure.

                          Can you say when this issue started for you?  Was it prior to January 1st this year, or only later?  This might help pin down any changes in the PHP code that might be related.

                          Bill

                          1 Reply Last reply Reply Quote 0
                          • S
                            Supermule Banned
                            last edited by

                            Thats a good question… It has been a long journey with Snort since it has a lot of problems with PfSense. You helped to make the package significantly better and that helped a lot!

                            A fair guess would be after we had the last discussion and I implemented your fixes.

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