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

    "Google 1e100 addresses" & Google invaled certificates "Common Name invalid2.invalid"

    Scheduled Pinned Locked Moved General pfSense Questions
    20 Posts 3 Posters 2.2k 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.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by stephenw10

      The first rule should never match anything. New connections, TCP:SYN, should always be passed.

      You want to block without logging TCP:ACK.

      Steve

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

        @stephenw10

        Stephen,

        I just not know, in principle everything which is allowed to pass is/should be passed via rules above these final rules.

        I would like to log all things which are not passed by the rules above these end rules, with the exception of the tcp-rules having states like "RA / PA / FPA"

        So for that reason three end rules:

        • first one intended to log tcp-S (because I would like to see what I perhaps should have passed)
        • the second rule is "not to log" the rest of the blocked tcp (the RA / PA / FPA etc). (for this test the log is on)
        • and the final rule is to log the rest (not being tcp)

        As said my problem is that the first two rules, intended to deal with TCP, do not work !! WHY O WHY !?

        1 Reply Last reply Reply Quote 0
        • stephenw10S
          stephenw10 Netgate Administrator
          last edited by

          What does the second rule actually look like?

          The first rule should only match anything if the pass rules above are wrong. So that fact it isn't is a good thing!

          You either need one rule to block anything TCP:ACK or you need three rules for each of those flah combinations. You can't match all three specific combinations with one rule.

          Steve

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

            @stephenw10

            first rule
            67353608-bb49-40bc-909c-f5525c809800-image.png

            second rule
            1eed5c07-5e32-4afd-b029-f5cffed5f6e3-image.png

            third rule
            3aa307ed-8186-44cb-9b9d-c35e3c967c9d-image.png

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              There are no flags set on that second rule. So it won't match.

              Change the first rule from SYN to ACK. Remove the second rule.

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

                @stephenw10

                ..... I do not understand any thing related to rules which have to capture a certain tcp state ....

                I tried
                58867366-922f-4397-bf89-991cac0ecd7f-image.png

                three rules in a row where I did expect the first rule to trigger on tcp packages having "RA / PA / FPA"

                I used
                9d365428-34fa-4243-8bab-1c8468d28953-image.png
                there and did also test with ^out of "ack"^. In both cases nothing triggered the rule

                So I tried the second rule, setting ^TCP Flags^ to ^Any flags^. This rule seems to fetch the FA etc.

                However, I really do not understand

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  Ah, OK. No that needs to be this:

                  Screenshot from 2022-05-26 13-47-40.png

                  It means: The ACK flag must be set, only check the ACK flag.

                  The rule that you have says: check all flags and match packets that have only ACK set. Which wouldn't include any of the blocked traffic you were seeing that all has multiple flags set.

                  Steve

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

                    @stephenw10

                    I am using these two rules now, which seems to work
                    a094b7e4-7e4d-4358-b229-b50f249e8f87-image.png

                    First rule is defined like this (I did try that before, but not likely good enough)
                    9ae9d349-95d5-4ae3-b4ef-4220a0774934-image.png

                    Still wondering what "Any Flag" is supposed to do

                    johnpozJ 1 Reply Last reply Reply Quote 0
                    • johnpozJ
                      johnpoz LAYER 8 Global Moderator @louis2
                      last edited by

                      @louis2 I personally wouldn't do it that way ;)

                      I would just turn off the default log. This removes all the other unwanted log stuff like multicast broadcasts and the like, stuff from link-local addresses, etc.

                      And then create a rules at the end to block, and only log stuff that has syn set. And then a rule to log any sort of common udp ports you want to see..

                      An intelligent man is sometimes forced to be drunk to spend time with his fools
                      If you get confused: Listen to the Music Play
                      Please don't Chat/PM me for help, unless mod related
                      SG-4860 24.11 | Lab VMs 2.8, 24.11

                      1 Reply Last reply Reply Quote 1
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        The 'Any flags' box will cause it to match TCP packets with any combination of flags. That means you can pass traffic that is asymmetric for example.

                        Steve

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

                          @stephenw10

                          The Filter TCP-ACK rule works, however ....... does change the firewall behavoir in a couple of ways. Suddenly new loggings occur which where not there before.
                          Conclusion is that this rule must be changing some FW internal state table ....

                          2b7663c5-5c0e-4910-9f39-b5067fdadcfe-image.png

                          Let me start with the logging above. I did never see that message before, but apart from that, it is communication between two devices in the same subnet. And communication within one subnet normally does not pass the FW. Where this is of course a strange situation, since one of the communication parties is the FW itself.

                          6d458d22-533a-4eed-ba37-d48e0c459329-image.png

                          Here we see a second effect. A message from the floating rule set "Default deny rule ipv4".

                          5081211b-096f-4234-b99d-c6c69d03f9c9-image.png

                          Here a set of the same "Default deny rule ipv4", however it is different since the source is somewhere on the internet (google / amazon)

                          c338983c-c8d3-49c1-b59e-523a9296d543-image.png

                          Switching off the TCP-ACK filter rule stops this "new" FW behavoir, we are back to the same situation as before.

                          So this TCP-ACK filter, has unexpected and unwanted side effects .......

                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            I suggest that all of those are because the IP you're testing from hit locked out of the firewall dues to excessive login attempts and the it's existing states were cleared. That applies before the user rules so it still hit and logged.

                            The arrow there shows it was blocked outbound on PCLAN_1G whicb is almost always out-of-state traffic because the state was closed.

                            The extra rule you have added does nothing more than block some traffic without logging before it hits your block everything rule anyway.

                            Steve

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