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

    Why is the default rule 1000000103 blocking LAN IP from querying mozilla IP?

    Scheduled Pinned Locked Moved Firewalling
    8 Posts 4 Posters 820 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.
    • L
      Luca1
      last edited by

      Hi guys,

      I have a default pfsense install on Netgate SG-1100 running 21.02-RELEASE-p1. All firewall settings are default out of the box install settings. LAN is set to default which is to allow ALL out.

      I was reviewing my firewall logs today because I started seeing some hiccups and I noticed the my laptops IP (192.168.9.50) which is on the LAN port is getting denied accessing some IPs via the default rule 1000000103 as per screenshot. The IP its blocking appears to be a mozzilla (firefox) IP but I saw apple IPs in there as well.

      To be clear, I do not have anything other than the default ALLOW all rule for LAN setup out of the box.

      Any ideas?

      Screen Shot 2021-05-25 at 8.58.01 AM.png

      V 1 Reply Last reply Reply Quote 0
      • V
        viragomann @Luca1
        last edited by

        @luca1
        pfSense has no connections for these blocked packets in its state table.
        Maybe the initiating SYN packets didn't pass pfSense and rather went out another way.

        Look here for troubleshooting: Troubleshooting Asymmetric Routing.

        1 Reply Last reply Reply Quote 0
        • L
          Luca1
          last edited by

          Is it possible that I was put on some type of a temporary block list? I tried logging in a few times and I put in the wrong username/password. I wonder if that caused all traffic from my IP to be rejected for a minute or so.

          V johnpozJ 2 Replies Last reply Reply Quote 0
          • V
            viragomann @Luca1
            last edited by

            @luca1
            The only function on pfSenses which I can think off to be responsible for this, is killing the states.
            Repeatedly entered wrong credentials might trigger an sshguard action to block further access to the webGUI and SSH. Possibly it kills all states pertaining the concerned source IP.

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

              @luca1 said in Why is the default rule 1000000103 blocking LAN IP from querying mozilla IP?:

              I wonder if that caused all traffic from my IP to be rejected for a minute or so.

              Not to some external IP like that. As stated already those are all out of state.. Your states reset/timedout or pfsense never saw the syn in the first place.

              If you lost internet, your gateway wasn't answering pings for example, and you have pfsense set to reset states then yeah you can see traffic like that.

              System / Advanced / Miscellaneous

              states.png

              If the the protocol is anything other than S only (syn) for a block for tcp traffic, then the reason is out of state.. Why its out of state needs to be determined, be it asymmetrical in the first place, or states are now gone that were there, etc.

              You can also see traffic like that if say a phone switches from cell traffic to wifi traffic, and didn't create a new session when it switched. That one is RST, which the client is saying CLOSE this session, and the others are FIN,ACK - also trying to close session.

              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 0
              • bingo600B
                bingo600
                last edited by

                I think i see something like this, when i wake my laptop from sleep.
                Seems file my FF just want to continue conversating with whatever it was talking to when i "closed the lid" , and the pfSense state is timed out looooong ago.

                /Bingo

                If you find my answer useful - Please give the post a šŸ‘ - "thumbs up"

                pfSense+ 23.05.1 (ZFS)

                QOTOM-Q355G4 Quad Lan.
                CPUĀ  : Core i5 5250U, Ram : 8GB Kingston DDR3LV 1600
                LANĀ  : 4 x Intel 211, DiskĀ  : 240G SAMSUNG MZ7L3240HCHQ SSD

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

                  ^ yup something like that could for sure cause out of state traffic.. A (ack) would be normal for that what he is seeing is the trying to close a session with the RA and FA that there is no state for.

                  But a browser or app could be trying to close out its old sessions before starting a new session, etc. Quite often these can just be ignored - But if you are seeing a ton of them, it doesn't hurt to track down what it is. Once you understand what it is - if you don't wan to see them you could filter them out of your logging.

                  I only log Syn blocks for this - I have no desire to see out of state blocks. If I was troublshooting an issues it takes only a second to turn full logging back on, etc.

                  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 0
                  • L
                    Luca1
                    last edited by

                    Thanks guys. Ticket resolved.

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