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

    [solved] Allow rule not working?!

    Scheduled Pinned Locked Moved Firewalling
    13 Posts 3 Posters 1.1k 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.
    • B
      b_chris
      last edited by b_chris

      Hello,
      I'm facing a strange problem (pfSense 2.5.2) and I can't really figure out, what is happening here.
      My VLAN20 should have access to everything (for testing). However connections from only one client are caught by the default deny rule all the time. When debugging I also introduced a reject all after the allow all rule (which I would assume should never be reached). However als you can see, the reject all still gets triggered.
      Am I stupid? Did I do something obviously wrong? I can't figure this out myself...

      Ruleset:
      Bildschirmfoto 2021-08-10 um 16.19.14.png

      Firewall log:
      Bildschirmfoto 2021-08-10 um 16.20.47.png

      The ruleset seams to be loaded (pfctl -sr excerpt):

      pass in quick on igb1.20 inet all flags S/SA keep state label "USER_RULE: Allow access to everything else"
      pass in quick on igb1.20 inet6 all flags S/SA keep state label "USER_RULE: Allow access to everything else"
      block return in log quick on igb1.20 inet all label "USER_RULE: test: explicit reject everything else"
      block return in log quick on igb1.20 inet6 all label "USER_RULE: test: explicit reject everything else"
      
      V 1 Reply Last reply Reply Quote 0
      • V
        viragomann @b_chris
        last edited by

        @b_chris said in Allow rule not working?!:

        My VLAN20 should have access to everything (for testing). However connections from only one client are caught by the default deny rule all the time. When debugging I also introduced a reject all after the allow all rule (which I would assume should never be reached). However als you can see, the reject all still gets triggered.
        Am I stupid? Did I do something obviously wrong? I can't figure this out myself...

        Check the TCP flag. The packets are out of state and therefor not caught be the filter rule.

        eb4541c4-0f1f-43b4-870f-656e07144274-grafik.png

        B 1 Reply Last reply Reply Quote 1
        • B
          b_chris @viragomann
          last edited by

          @viragomann
          Thanks! Honestly I completely ignored the TCP-Flags and until now I don't have an extended knowledge about them.
          Do you know any easy digestible source where I can read about that? I'm not really sure whether the PSH, ACK (that's what the PA means, right?) should not really happen (and the device has some faulty implementation) or if this is some kind of valid special use case.

          B johnpozJ V 3 Replies Last reply Reply Quote 0
          • B
            b_chris @b_chris
            last edited by

            I think I found a resource for that: https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html

            I'll do some reading on this. But seams like pfSense is exactly doing what it should do ;)

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

              PA doesn't really mean anything other than just ack other than the PSH flag also set..

              Here is some info on the PSH flag
              https://packetlife.net/blog/2011/mar/2/tcp-flags-psh-and-urg/

              The real issue is that as @viragomann has stated is its out of state.. Why that is - could just be that your states have been reset, say on loss of wan pfsense can be set to flush all states. Or if this is wireless and your client moved from say cell to wifi and just trying to use the same connection, etc.

              If you see lots of these - or you see them with SA, ie syn,ack - that yeah that could mean you have asymmetrical routing issue..

              Could just be your device has not really sent enough data to keep the state open and pfsense has closed it.. If you see these now and then I wouldn't worry about it too much.. Is when you see them all the time, or floods of them then yeah I would look into it. I don't even log such traffic either on my wan or my lan.. I only log stuff that is blocked via SYN blocks.. Out of state traffic now and then can happen with a stateful firewall and devices that try and use the same session even if hasn't sent traffic in ages.. Phones can be horrible at this for example.

              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

              B 1 Reply Last reply Reply Quote 1
              • V
                viragomann @b_chris
                last edited by

                @b_chris
                https://en.wikipedia.org/wiki/Transmission_Control_Protocol

                The filter rules only affects only the initiating SYN packet. If the SYN does not pass pfSense, there is no entry in its state table for that connection and all other regarding packets are blocked anyway.

                So seeing this in you filter log can mean, that the SYN packet doesn't pass pfSense (asymmetric routing) or that pfSense removed the alreay the entry from the stat table due to timeout.

                B 1 Reply Last reply Reply Quote 1
                • B
                  b_chris @johnpoz
                  last edited by b_chris

                  @johnpoz
                  Thanks for replying. The WAN connection is stable and the client is wired. But when I think about it, it wouldn't surprise my, if the client is the problem. It also seams to be bit buggy regarding the communication with the DHCPv6 on pfSense.
                  --> pretty sure the network stack of the client is the problem here. I'll report that to the manufacturer (and probably won't get a reply ;))

                  johnpozJ 1 Reply Last reply Reply Quote 0
                  • B
                    b_chris @viragomann
                    last edited by

                    @viragomann
                    Thanks for explaining! I'll so some reading. As stated in the other reply, I'm pretty sure, that this client is buggy. Had some network problems with it before (and with no other client in my network)...

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

                      Yeah see my edit..

                      Lets say for example you had a website in some tab or app in the background, and hasn't done anything in a long time.. And then you bring it to the foreground and it tries to just use the same session even though nothing has been sent in hour or more, etc.. The stateful firewall will close states that have not seen any traffic.

                      Its not a big deal - since the client upon seeing that session no longer working should open a new session via sending syn, etc. When then the firewall if the traffic is allowed would open a new state for.

                      Edit: another example of this is say a device coming out of standby or sleep mode.. If it tries to use an old session which the firewall has closed because of no traffic in X amount of time than yeah that would be blocked, and the client would have to open a new connection via sending syn.

                      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

                      B 1 Reply Last reply Reply Quote 1
                      • B
                        b_chris @johnpoz
                        last edited by

                        @johnpoz
                        I see. That would explain why I don't see any degradation of the function of the client --> it probably just opens a new session and continues.
                        If I find the time I'll get some traces and have a look at them via wireshark to learn something.

                        Thank you @johnpoz and @viragomann !

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

                          Why a firewall has to close states.. Is only so many states can ever be open.. Since it uses resources to track these states.. There is many issues where the state is not properly closed via fin or rst, etc. If the firewall never closed these states than at some point you would run out of firewall resources to track them.

                          Say your pc just losses power, or application bad programming or crash, or say your phone just drops off the wifi.. So tcp has timeouts that will auto close states with no traffic seen on that state after specific amount of time.. These can be edited - but would not suggest you mess with the defaults..

                          So again - unless you are seeing floods of these, or always seeing SA blocks (major hint of asymmetrical traffic) I wouldn't worry about it too much.

                          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

                          B 1 Reply Last reply Reply Quote 1
                          • B
                            b_chris @johnpoz
                            last edited by

                            It's definitely not a flood of entries.
                            With the explicit reject rule it was pretty exactly one block an hour as TCP:PA. With the default deny rule it's a burst of the following sequence every hour: 1* TCP:PA, 2* TCP:FA, 8* TCP:FPA.

                            Won't worry anymore about these :) But definitely good to understand, what's causing the messages!

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

                              @b_chris said in [solved] Allow rule not working?!:

                              2* TCP:FA, 8* TCP:FPA.

                              Yeah that would be normal - when the client tries use a session, and the state is closed.. Then it would try and close it via FIN.. I would expect, if it doesn't get an answer to its FIN, that at some point it would send a RST.. Basically saying ok, not sure if your getting my FINs - but I am done with this connection - so if you happen to get this RST you can close the connection ;)

                              Here is quick image found showing open and close of a tcp connection. You quite often see the FIN,ACK together.. Seems this image also has a typo of massage vs message ;) But it gets the idea across of how a connection is opened, and then closed..

                              tcp.jpg

                              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
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.