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

    Big issues related to Firewall logging.

    Scheduled Pinned Locked Moved Firewalling
    13 Posts 2 Posters 1.0k Views 2 Watching
    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 Offline
      SteveITS Rebel Alliance @louis2
      last edited by SteveITS

      @louis2 #2 is not a problem per se…IGMP/options drops are logged now.

      https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#packets-with-ip-options

      You can create a rule to match and not-log them.

      Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
      When upgrading, allow 10-15 minutes to reboot, or more depending on packages, and device or disk speed.
      Upvote 👍 helpful posts!

      L 1 Reply Last reply Reply Quote 0
      • L Offline
        louis2 @SteveITS
        last edited by

        @SteveITS said in Big issues related to Firewall logging.:

        https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#packets-with-ip-options

        Steve,

        I tried a lot but the behavoir is definitively not ok and in my opinion disgusting.

        I tried to stop this logging adding extra rules in front of the rule generating the logging. Nothing stops it!

        e8cd896f-8b13-459d-a1c4-6e83dd266ff6-image.png

        As you can see three rules:

        1. a rule to block IGMP with options set
        2. the same rule without options set
        3. the >>pass rule without Logging<< generating the logs .....

        IMHO nothing justifies this behavoir !!

        da45384c-a2d8-4119-be53-a02a9e305140-image.png

        S 1 Reply Last reply Reply Quote 0
        • S Offline
          SteveITS Rebel Alliance @louis2
          last edited by

          @louis2 in your screenshot both IGMP rules have “ Log packets that are handled by this rule” checked.

          It should be protocol IPv4 IGMP, interface LAN, log unchecked, and that’s it.

          Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
          When upgrading, allow 10-15 minutes to reboot, or more depending on packages, and device or disk speed.
          Upvote 👍 helpful posts!

          L 1 Reply Last reply Reply Quote 0
          • L Offline
            louis2 @SteveITS
            last edited by

            @SteveITS

            Steve ... you overlooked something ....

            It are not those rules which are causing the logging, it is the rule at the bottom which is causing the logging !!!

            I now even add four rows above that rule trying to stop the logging. All those rules have logging on because I want to see it those rules are triggered.
            They are not as you can also see from the counters

            f7dd8cf8-4e50-4cb4-928e-67ebe8be1e41-image.png

            S 1 Reply Last reply Reply Quote 0
            • S Offline
              SteveITS Rebel Alliance @louis2
              last edited by

              @louis2 please show a screen cap of the rule.

              We created a not-log rule on all routers we manage. The behavior change was new in 24.03 or thereabouts.

              Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
              When upgrading, allow 10-15 minutes to reboot, or more depending on packages, and device or disk speed.
              Upvote 👍 helpful posts!

              L 1 Reply Last reply Reply Quote 0
              • L Offline
                louis2 @SteveITS
                last edited by

                @SteveITS

                The 'logging rule'

                367cece3-1a51-48fc-a889-3f199d5c9bba-image.png

                Let me know if you nee more!

                S 1 Reply Last reply Reply Quote 0
                • S Offline
                  SteveITS Rebel Alliance @louis2
                  last edited by

                  @louis2 The IGMP one.

                  Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
                  When upgrading, allow 10-15 minutes to reboot, or more depending on packages, and device or disk speed.
                  Upvote 👍 helpful posts!

                  L 1 Reply Last reply Reply Quote 0
                  • L Offline
                    louis2 @SteveITS
                    last edited by

                    @SteveITS

                    Below the rule with advance options set. The other one is identical without the advance options

                    db4cb3a0-40fc-4faf-9266-d52fd65f9ff1-image.png

                    71bfd899-046e-4f39-9503-d1002455158a-image.png

                    L 1 Reply Last reply Reply Quote 0
                    • L Offline
                      louis2 @louis2
                      last edited by

                      I leave home for a couple of hours, will respond afterwords if required

                      S 1 Reply Last reply Reply Quote 0
                      • S Offline
                        SteveITS Rebel Alliance @louis2
                        last edited by SteveITS

                        @louis2 Try a Status/Filter Reload to ensure they're loading?

                        here are mine:
                        d446b62c-d001-4162-aeaa-948f7d407746-image.png

                        no advanced anything set:
                        6f24810e-d7e3-428a-bd2f-4bbb2dfb6ac6-image.png

                        Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
                        When upgrading, allow 10-15 minutes to reboot, or more depending on packages, and device or disk speed.
                        Upvote 👍 helpful posts!

                        L 1 Reply Last reply Reply Quote 0
                        • L Offline
                          louis2 @SteveITS
                          last edited by louis2

                          @SteveITS

                          Hum ... I did reboot the FW ..... which changed the behavior .... what should not be the case ....

                          4a434c5e-85ba-4b72-a928-3c8985ce6849-image.png

                          The first rule in my 'rule-group' blocks the packet now

                          Also in the log a message from the 0.0.0.0 filter rule
                          not clear why sometimes that rule matches and sometimes not

                          The whole thing is bizar in multiple ways .....

                          note: alias MyIPV4network = '192.168.0.0/16'

                          L 1 Reply Last reply Reply Quote 0
                          • L Offline
                            louis2 @louis2
                            last edited by

                            I did a small modification in my rule group.

                            • A small change in the rule description and
                            • I reordered the rules so that the rule without iP-options comes before the rule with IP-options set.

                            ab160041-b646-49cf-bd66-3ded176aa5e1-image.png

                            c760c5e7-6843-4ee5-a322-6d8f32d3361c-image.png

                            Note that there are a couple of addresses:
                            source 0.0.0.0 destination 224.0.0.22
                            source 192.168.100.2 destination 224.0.0.22
                            source 192.168.100.1 destination 224.0.0.1

                            192.168.100.1 = vlan gateway
                            224.0.0.22 = is used for the IGMPv3 protocol. This protocol is used by hosts to manage its multicast interests
                            224.0.0.1 = is a well-known multicast address reserved for the all-hosts group, meaning it addresses all devices that have joined the multicast group

                            192.168.100.2 = address inside my VM-lan assigned to the VM-host. I do not know why it behaves like this, however for this moment (during this test) I leave it as it is.

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