Echo Devices all generating blocks for TCP:RA & TCP:PA

ck42

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.

johnpoz

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.

ck42

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!

johnpoz

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

ck42

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.

johnpoz

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.

ck42

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!

ck42

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" checkboxes

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

johnpoz

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.

ck42

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?

johnpoz

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.

ck42

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.