Weird Blocks in Network
-
Tried accessing my Pentair controller today and couldnt get a connection. Looked at the firewall logs and noticed that I'm getting blocked from my internal network.
I connected it to another port and I got access, but looks like there is still some blocking going on in the firewall.
For reference I have the OPTx ports all bridged.
I haven't touched the firewall rules, how is this happening and how can I fix it?
Action: block
Reason: match
Tracker ID: 1000002520
Matched Rule: unavailable
Associated Rules:
@73 block drop in log on ! bridge0 inet6 from 2601:6c0:8000:2d7::/64 to any ridentifier 1000002520
@74 block drop in log inet6 from 2601:6c0:8000:2d7:ad:79ff:fea1:c400 to any ridentifier 1000002520
@75 block drop in log on bridge0 inet6 from fe80::2ad:79ff:fea1:c400 to any ridentifier 1000002520
@76 block drop in log on ! bridge0 inet from 192.168.0.0/24 to any ridentifier 1000002520
@77 block drop in log inet from 192.168.0.1 to any ridentifier 1000002520Action: block
Reason: match
Tracker ID: 1000000103
Matched Rule: unavailable
Associated Rules:
@6 block drop in log inet all label "descr=Default deny rule IPv4" label "tags=ruleset:cafbe50a6fd301f4" ridentifier 1000000103
-
@hypnosis4u2nv those are out of state blocks.. That is a Reset, ack.. State was closed and then pfsense saw those..
Could be typical noise.. But yeah if your states get flushed on pfsense you can see all kinds of noise from that because any traffic it sees after the state has been close would be out of state.. It would need to see a syn again that is allowed to open a state.
For some reason that 192.168.0.74 decided it should send a bunch of reset, acks and pfsense already had the states closed, etc.
-
I just added a rule to allow source IP 192.168.0.74 to any for now and the blocks have stopped. I'll disable the rule tomorrow and try again.
It's one of those crazy things that had me thinking something was wrong with the hardware until I checked the firewall logs and saw it being blocked which is unusual.
-
@hypnosis4u2nv that rule you create would have nothing to do with RA.. Again those are out of state blocks..
-
Would a state reset help?
-
@hypnosis4u2nv why would you flush all your states? Lets take that top one.. You had a connection open from 192.168.0.99 to 192.168.0.74 on port 80.. Or you sent a syn atleast or you would of never gotten anything back. Now for some reason 0.74 sent you as RST (reset) and an ack..
Clearly you were talking to this before or attempting, because devices don't just send RST to some random IP..
What is weird is why you see it on your opt1 interface, and also on your lan interface?
Ah you have bridge setup.. So that is a rule you created? Please post up your rules for your opt1 and your lan and any floating rules (if you have any).
And how you have things actually connected.. So your lan interface is part of a bridge?
-
Unfortunately I had accidently triggered a reboot of the router when I was switching network cables, so that probably explains why there isn't more info in the logs. Those were what were available when it finished rebooting.
-
@hypnosis4u2nv so those were during a reboot.. I wouldn't worry about them too much then.. Like I said they are out of state.. If 74 could talk to 99, can it still talk to it now..
Seeing out of state now and then is going to happen now and then.. And some devices/oses/applications can send a RST when closing a session as a shortcut.
Are you seeing them
What is the setup of your bridge? The only scenario where a rule like .99 can talk to 90 that would ever be seen on the firewall is if you have a bridge and are wanting to stop devices from talking to each other. But I don't see any block rule above them. So they would never be evaluated.
Same with that igmp rule.. why would you need to allow for igmp when you have an any any rule right above it.
-
I set those in the past (long time ago) from the firewall logs because of the same behavior when they were getting blocked.
I'll disable for now and see what happens.
