Unable to match fw rules to eero wap device ips
-
There are ips in my iot network that I clearly have rules set to match. But packets from these ips are continuously default blocked according to the logs.
I've set up a test case where I have a an allow all rule that is pass ipv4 any source/protocol/port/destination/etc on this interface but the traffic from these devices are still "mostly" blocked.
I even used the easy-pass option on the individual default block lines in the logs to setup pass rules according to what pfsense sees as being blocked and that doesnt work either.any ideas
pass any + easy passes
default block logs
easy pass ex window -
-
@steveits this definitely sounds like the behavior.
The Doc says: "In each case, the log entries are harmless and do not indicate a blocked connection. All stateful firewalls do this, though some do not generate log messages for this blocked traffic even if all blocked traffic is logged."
So it sounds like I can just safely ignore but is there a way to verify that this is the case? If this were something happening occasionally I wouldn't care but with these eeros it's constantly every day.
-
@pfscents can you post up some of these logs your seeing?
Out of state traffic is common, especially with say wifi stuff, or stuff that goes into standby.
If you were having issues with connectivity wouldn't you know, or wouldn't you hear complaints?
You could remove such entries from your log by disable the default deny logging, and then just create a deny rule of your own that only logs syn blocks.. Anything that is not a syn that is blocked is either asymmetrical traffic - which hope you would of already notice, blocks that scream asymmetrical are SA (syn,ack) blocks. If they are just A or FA or RA, etc. these normally just mean they are out of state..
If your not having an issue with states being reset for some reason, then normally they can just be ignored - if they are bothersome for you to see those in the log, I would just suggest not logging them.
When some device attempts to use an old session that state has timed out on the firewall - the device will just create a new session by sending a new syn..
-
@johnpoz I did post some examples in the original post but here are a couple more since then. I'm not logging passes in these pics
eero guest net ip logs
eero node ip logsAnd no, for the most part there doesn't seem to be any connectivity issues. I've been trying learn networking on my own so I'm trying to read logs, clean them up, and understand everything I'm seeing.
when you say "create a deny rule of your own that only logs syn blocks" what are "syn blocks"? Is that an option in the firewall rules I can choose? Because making my own rule for that sounds like a good idea to observe this.
-
@pfscents so RA or FA are common after a device doesn't get an answer, he will say hey lets close this with FIN, if doesn't get an answer then yeah he will send RST, yeah hey if you happen to get this CLOSE this!!
You might see multiple entries for these, especially the A or FA, since those are normally retransmitted, etc.
What are those devices the .151 and .152 - are they wireless devices? Are they iot type devices that might of gone into a sleep more or standby sort of mode and only wake up every so often and they attempt to resuse a previous session.
I don't see any SA in there - so unless you got some actual problem your trying to troubleshoot that is not working - those just seem like your typical log spam that can be seen when logging out of state traffic.. .
-
@johnpoz I see and thanks for taking the time to explain.
"What are those devices the .151 and .152 - are they wireless devices? Are they iot type devices that might of gone into a sleep more or standby sort of mode and only wake up every so often and they attempt to resuse a previous session."
These are the 2 eero wireless mesh nodes that I have static ips on. Its possible they do standy/sleep but I fairly certain some of the devices connected to them do ie. google nest thermostats, smart tv, sprinkler system. -
@pfscents if your really curious... I would log all their traffic via a sniff (packet capture) on pfsense for long enough time to see when it opens a session via a syn.. And then how often does it continue this conversation actively..
It could be it phoning home for something - then not doing anything for some length of time, and then trying to use it again after the tcp timeouts have closed that session on the firewall.
You can track a specific session via the source port the device used to open the session.
Here is the thing with many of these sorts of devices - the coding is lacking - they might not be sending keep alives, or they don't send them enough to keep the session active. They might just be too lazy to even just close the session after they have exchanged whatever info they wanted to exchange.
Have seen some really lazy sort of programming where an application will just send a RST vs going through the whole fin, finack proper way to close off a session, etc.
Other than just curiosity there isn't much you can do about this.. Not like you could tweak the device to proper close a session, or if they want to maintain it send keep alives often enough to keep the states active, etc.
You could find yourself getting pretty deep down the rabbit hole to what is going on - just to find out the devices coding is shit ;) And the only solution to your log spam is to not log it ;)
The devices normally do not send a lot of traffic to the mother ship, so logging an extended period shouldn't get too freaking huge.. You can have packet capture set to 0 for number of packets, and just let it run.. Then come back to it like 24 hours later and see what is up with the sessions.. If need be in the packet capture you can set packet length to something small - so even if they end up moving a bunch of data, your sniff would be of small size to work with. Really what your interested in is the start of sessions, do they close - do they send keep alives, etc. etc. If you don't see traffic in either direction to keep it alive - then yeah the session would time out on the firewall. And then if traffic does come up with the same source and dest ports from that IP the state would be gone, etc.
-
@johnpoz
Thanks again for the info! Ive been needing an excuse to dive in further and this is perfect. Ill give this a shot. Thanks again!
