What does TCP:SEW means?
-
I'm receiving many TCP:SEW on a specific port which is related to Microsoft Lync federation. I'm continuing to lose federated partners on Lync and not sure if this SEW has anything to translate and look at? or look for.
anyone? ???
-
S would be SYN, meaning it's starting a new connection.
E is ECE "indicate that the TCP peer is ECN capable during 3-way handshake"
W is CWR "Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set"If you're seeing a SYN blocked it's usually because it's not matching a firewall and/or NAT rule as you expect.
Should that software be opening up a port with UPnP? Or some other way?
-
The traffic is allowed, it doesn't block it and that's what makes it even more odd! The thing is I would like to know if seeing such traffic flagged with the SEW is normal or indicates there's a problem ?
The port is actually matching the rule I have enabled .. as I see that outgoing and incoming connection are coming/going to the right host/destination ports for the server hosted in my data center/client connected.
this logged connection shows that my server is sending packet to destination partner's IP on port 5061 for federation purpose on Lync.. still I'm unable to communicate with this partner.
Dec 27 17:12:38 DMZ 10.20.10.150:64121 134.56.3.168:5061 TCP:SEW
This happened only 2 days ago. so I'm not sure what's the case, before that I had federation with MSN/Skype so My Lync could talk normally to Skype and MSN contacts. now I can't but this was logged on my servers as a certificate issue and i'm intending to reinstall the certificates and hope the issue gets fixed with all of them.
But this other partner was working normally. now not ??? ???
-
The TCP flags aren't likely to be of any relation, you're logging it as passed, it's getting passed. Just having a state created doesn't necessarily mean end to end connectivity is working though, analyzing a packet capture would determine that. If the TCP session is legit in a capture, then you know you have an application-level issue, not a network issue.
-
So it's most likely a certificate issue then, Would certificate issue causes packets to not being sent or received as expected by the server application ?
