SYN Timeout: Need a brief explanation

I need a quick explanation of what this means.

Jun 25 11:40:40 dsgatekeeper Jun 25 2008 11:40:40: %PIX-6-302014: Teardown TCP connection 43245574 for outside: to inside:in-www/80 duration 0:00:30 bytes 0 SYN Timeout

What types of things could cause this?
Who is Participating?

Improve company productivity with a Business Account.Sign Up

dbanttariConnect With a Mentor Commented:
That's correct-- however, if the ACK was sent back but lost due to packet loss, then a properly functioning host would resend the ACK several times, and one of them would most likely have gotten through.
That's indicating that someone asked to start a TCP connection, but never followed through.  Port scanners will commonly produce this symptom, as they'll send a lot of TCP SYN ("synchronize [sequence numbers]") packets, then never follow up on the response.

It's the TCP equivalent of getting called by a telemarketer, answering the phone, then getting nothing but dead silence.  Eventually you get frustrated ("time out") and hang up.
maytawnAuthor Commented:
Where are we at in the process of the handshake?  Did I send the SYN, but not get a response back?  What response am I waiting for that I do not recieve and eventuallty time-out?
NEW Internet Security Report Now Available!

WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network.  Check out this quarters report on the threats that shook the industry in Q4 2017.

You got a SYN, sent back a SYN/ACK, but then there was no further communication.

If you get a LOT of those from the same source, that's called a SYN Flood attack.

Pretty pictures here:
maytawnAuthor Commented:
OK... so the time-out is caused by not receiving an ACK.  Just to be clear... This could be caused by one of the following:
1) The SYNACK (that I sent) was never recieved.  
2) The SYNACK was received, but ignored and no ACK was sent
3) The SYNACK was recieved and an ACK was sent back, but the packet was lost in transit and sever arrived.

Oh-- one last note:  If a properly functioning host had decided not to follow through on the connection-open SYN request, it would have responded with a RST packet when it received your SYN/ACK packet.  That would not have produced the timeout message.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.