• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3985
  • Last Modified:

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:74.202.21.66/62674 to inside:in-www/80 duration 0:00:30 bytes 0 SYN Timeout

What types of things could cause this?
0
maytawn
Asked:
maytawn
  • 4
  • 2
1 Solution
 
dbanttariCommented:
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.
0
 
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?
0
 
dbanttariCommented:
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:
http://en.wikipedia.org/wiki/SYN_flood
0
The Firewall Audit Checklist

Preparing for a firewall audit today is almost impossible.
AlgoSec, together with some of the largest global organizations and auditors, has created a checklist to follow when preparing for your firewall audit. Simplify risk mitigation while staying compliant all of the time!

 
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.

Correct?
0
 
dbanttariCommented:
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.
0
 
dbanttariCommented:
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.
0

Featured Post

[Webinar] Improve your customer journey

A positive customer journey is important in attracting and retaining business. To improve this experience, you can use Google Maps APIs to increase checkout conversions, boost user engagement, and optimize order fulfillment. Learn how in this webinar presented by Dito.

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now