Echo Devices all generating blocks for TCP:RA & TCP:PA
-
They are generating out-of-state traffic?
Sorry, but that's the deal. Why? Really difficult to say without more information. No idea what sort of traffic those need to pass.
The default timeout for an established TCP state with zero traffic on it is 24 hours. I highly doubt that Conservative is necessary for TCP connections.
-
As I recall, this setting has been there since the 1.x days....due to recommendations for networks with VoIP phones, which I have.
I've switched it over to Normal and have also cleared the states for the Echo devices and will monitor.
Thanks! -
Looks like I'm still seeing this traffic....and on other devices as well.
What I don't know is if this is considered normal or not. As far as I can tell, all is working correctly.Question: If I wanted to just prevent this traffic from being logged, I could just create a rule to match it - and reject. But what TCP flag settings would I configure to do this? There's the 'set' and 'out of' checkboxes. Would I just check the PUSH and RESET boxes for 'set' ?
Would this break anything unintended? -
I have 3 different echo boxes, 2 dots and 1 show.. I do not see any out of state noise. Then again I don't log default and only log blocked packets with SYN set on my wan, and specific blocks on my other networks on the lan side..
I could turn default logging back on to see if seeing the same thing, but I am not having any issues with my echos that is for sure.. If your devices are connecting and reconnecting to your wireless and trying to use a previous session, etc. Guess its possible for them to generate out of state, etc.
If you do not like the noise, just turn off default logging. I log on the WAN blocked syns - just because I like to see what ports the bots and such are hitting.. Its your typical 22, 23, 3389 as the heavy hitters. But you can see when there is a new bot/worm in the wild hitting some new port ;) So its interesting to watch that traffic. On the lan since I do not do any outbound blocking.. I would only turn on logging of default rules if looking to troubleshoot something, etc.
-
Appreciate the thoughts.
I usually leave the default logging on because I'm filtering outbound traffic....and so there's always some new 'need' popping up (I know...that's one of the downsides of outbound filtering). Plus...I just like to see what sort of crap my home devices are doing that they're not supposed to. :) Gets interesting sometimes. -
Well in such setup, yeah there is always going to be noise ;) Phones are horrible when they switch from say lte data to wifi data trying to use the same session vs opening with syn again unless connection fails, etc.
Also if your seeing FA or RA its possible the state has been closed and what your seeing is duplicate or retrans of those packets..
I'll turn default logging on for that vlan my echo's are on - and let it run for a few days to see if I see lots of out of state.. Let you know.
-
Ahh...that may explain why I'm see a good bit of this type of traffic on my phone (work from home).
Appreciate you going out of your way to check the Echo traffic! -
Well that did not take long - but these are FA..
That is my show.. Trying to close session. Now that "could" be duplicated because of wifi?? But I doubt it - or more like just misconfigured application/service. Hey I didn't get my answer to my FA.. So going to send it again..
If you look at time stamps - its looks like retrans on the FA, see how the timestamps back off in time between..
-
All of mine are either PA or RA.
Looking closer at it, both Echos are only PA...and the two dots are a combination of RA and PA.
No FA's at all on mine. -
RA would be a reset..
I let it run like this for a while to see what and amount seeing..
edit: Yeah seeing some more
You would really have to watch the full conversation via say a sniff to try and figure out what is going on when the connections goes to close.. And where its breaking down, prob going to be without knowing what is happening inside the conversation.. Could just be bad coding..
To be honest as long as things are working, I would prob just turn off the default logging so you don't see this sort of stuff. If you wanting to catch stuff that might be required you could log block just SYN.. So you would see if say application needs to talk on port XYZ, and you don't have XYZ open.. But you wouldn't see all this out of state noise.
-
Yeah, really not feeling like doing a bunch of packet peeking to chase this down when the devices appear to be working anyway.
I'll try changing the default to just block SYNs. Sounds like the easiest way of dealing with this.Thanks!
-
Okay...spent enough time trying to figure this next step out.
I've never needed to play with the firewall rules TCP flags before...and I'm not quite getting how to set this up using the "set" and "out of" checkboxes.I found one older posting that came REALLY REALLY close to explaining it well enough...but it left just enough ambiguity that I can't be sure.
This woudl be for my Default 'catch all' Reject logged rule on the LAN interface:
I know I need to set the SYN on the "set" checkboxes.
I think I need to set just the ACK box on the "out of" checkboxesIs this correct?
Essentially, I just want to match the initial Syn flag when the handshake starts...and not the other handshake packets that also happen to have the SYN flag set. -
You do understand your default deny is still there right, your just not logging it ;) If all you want to block so you can log the syn, is the syn set..
Here is rule I have on wan to catch the syn attempts.
If this is on your lan - you can set reject, but I would never suggest you reject on wan for unsolicited traffic to any port.
-
Yep, I understand the implicit final block. :)
This will just be my catchall rule to log unallowed LAN traffic...except now it will only reject/log that same traffic with the SYN flag...and cut out all the out of band noise.
For what should be obvious reasons, I'd NEVER 'Reject' on the WAN side.
But...question - How does this checkbox combo work? Like I mentioned, the 'set' part makes sense....but how exactly is the 'out of' SYN option working here?
EDIT: Found something on this FINALLY!
"The first row controls which flags must be set to match the rule. The second row defines the list of flags that will be consulted on the packet to look for a match"
So....based on this, it seems like in the "out of" row, I should select RST and PSH as well, right?
-
no your only looking for stuff that has syn set.. When syn is set. So you care if S and PSH set? Why do you care if syn and psh are set.. As long as syn is set is all you care for, so you want to look at packets for SYN, is it set.. Great. log it.
-
You're right....somewhere along the line, my logic went completely sideways!
I've got it set now with the last rule on the LAN side being a Reject ANY/ANY with the "set/out of" boxes checked for SYN.
...and for testing, set it to log to make sure it's catching the stuff I want it to catch.If that is working, then I'll stop logging on that rule and then create another Reject rule to catch and log everything that makes it past that new SYN rule.
EDIT: Actually, that new rule will just end up catching the 'normal' stuff that I do want to log....all of the non-TCP:RA/PA packets. Okay...I think this is where I starting going sideways earlier...while trying to figure out a way to prevent this. Somehow, I need to create a rule that specifically matches TCP:PA/RA packets...and ONLY those.
