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

[Luca1]

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?

[viragomann]

@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.

[Luca1]

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.

[viragomann]

@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.

[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

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.

[bingo600]

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

[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.

[Luca1]

Thanks guys. Ticket resolved.