skip to content

When a TCP client sends a SYN, how do open, closed and silently filtered ports respond, and how does each attempt end?

level: middleimportance: should knowfreq 50%

answer

  1. three answers: SYN-ACK, RST, nothing
  2. no connection record means reset
  3. the reset must acknowledge the SYN
  4. silence means retransmission with backoff
  5. ICMP soft versus hard errors

basics

~20 s

An open port answers SYN-ACK. A closed port on a live host sends a RST acknowledging the SYN, failing the attempt within one round trip. A silent filter answers nothing, so the client retries its SYN with backoff until it gives up.

solid answer

~50 s

If something is in `LISTEN` on the port, the server replies with a `SYN-ACK` and the handshake completes. If the host is up but nothing listens, RFC 9293 handles the SYN as arriving for a `CLOSED` connection: because the SYN has no ACK flag, the host sends `<SEQ=0><ACK=ISN+1><CTL=RST,ACK>`. The client in `SYN-SENT` accepts that reset because it acknowledges its SYN, reports a connection reset (socket APIs usually call it *connection refused*) and goes to `CLOSED`. If a firewall drops the SYN, nothing comes back; the client retransmits with exponential backoff, and RFC 9293 requires a stack to keep retrying a SYN for at least 3 minutes unless the application gives up first. A router or firewall may instead return an ICMP Destination Unreachable: port unreachable (code 3) is a hard error that SHOULD abort, while codes 0, 1 and 5 are soft errors the RFC says MUST NOT abort the attempt by themselves.

go deeper

for a junior

Recall the three outcomes of a SYN: a SYN-ACK from an open port, a reset from a closed port, and silence from a dropping filter, and which of them fails fast.

for a middle

Explain where the reset comes from under RFC 9293, why its acknowledgment is the ISN plus one, and why silence leads to SYN retransmission with doubling timeouts.

for a senior

Diagnose from the symptom: separate fast refusal, slow timeout and ICMP-driven failure, remember that a rejecting firewall mimics a closed port, and know the soft and hard ICMP classes.

for a principal

Decide how services and firewalls in your estate should fail, drop or reject, weighing fast client feedback against revealing which ports exist, and set connect timeouts to match.

## Three answers to one SYN A client that sends a TCP `SYN` learns a lot from what comes back, and from what does not. The possible outcomes: | Situation | What comes back | Client's state | Time to fail | |---|---|---|---| | Port open, something in `LISTEN` | `SYN-ACK` | `SYN-SENT` to `ESTABLISHED` | does not fail | | Host up, nothing listening | `RST` with `ACK` set, acknowledging the SYN | `SYN-SENT` to `CLOSED` | about one round trip | | Firewall or filter silently drops the SYN | nothing | stays `SYN-SENT`, retransmitting | until the retry limit or the application's timeout | | Router or firewall reports a problem | ICMP Destination Unreachable | depends on the code | one round trip, or retries | | Firewall configured to reject with a reset | `RST` generated by the firewall | `SYN-SENT` to `CLOSED` | about one round trip | ## The closed port: reset generation When a segment arrives for which no connection record (TCB) exists, RFC 9293 section 3.10.7.1 treats it as arriving in the **fictional `CLOSED` state**: - Any incoming segment that does not itself carry `RST` causes a `RST` to be sent in response. - Because a SYN has its ACK flag off, the reset is `<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>`. The segment length counts the SYN flag, so the acknowledgment is the client's ISN plus one. - The client in `SYN-SENT` accepts a reset only if its ACK field acknowledges the SYN it sent (RFC 9293 section 3.5.3). This one does, so the client signals "connection reset" to the application, enters `CLOSED` and deletes its record. Socket APIs commonly report this outcome as *connection refused*. The acknowledgment check matters: it keeps a stale reset from an earlier connection from aborting this attempt, and it forces anyone forging a reset without seeing the SYN to guess the client's ISN. No application is involved in any of this. The refusal comes from the host's TCP itself, which is why it is fast. ## Silence: retransmission and the 3-minute floor If nothing answers, the client cannot distinguish a dropped SYN from a lost one, so it retransmits: 1. The first retry waits for the initial retransmission timeout, which RFC 6298 says SHOULD be 1 second (the RFC it replaced used 3 seconds). 2. Each further retry doubles the wait, so with a 1-second start the retries go out roughly 1, 3, 7 and 15 seconds after the first SYN. 3. RFC 9293 (carrying over RFC 1122) requires the retry threshold for a SYN to allow retransmission for **at least 3 minutes**. The application may give up sooner. How long a connect attempt actually hangs is therefore set by an implementation's retry count or by the application's connect timeout, not by a single protocol constant. Silence can also mean the host is simply off: a powered-down host sends nothing, and a router in front of it may or may not report anything. ## ICMP errors during connection setup A router or firewall may answer a SYN with an ICMP Destination Unreachable instead of staying silent. RFC 9293 section 3.9.2.2 classifies the IPv4 codes: - **Soft errors:** codes 0, 1 and 5 (code 5 is source route failed; the other two report that the destination network or host cannot be reached). A TCP implementation MUST NOT abort the connection on them and SHOULD make the information available to the application, because routing may recover while the SYN is retried. - **Hard errors:** codes 2 to 4, which include protocol unreachable (code 2) and port unreachable (code 3). The implementation SHOULD abort the connection. RFC 9293 also notes that many implementations treat soft errors as hard errors during connection establishment, so an application may see a fast failure where the specification expects retries. ## Reading the symptom - **Instant refusal:** something at that address answered with a reset. Usually that is the host's own TCP with no listener on the port, but a firewall set to *reject* rather than *drop* sends the same `RST` on the host's behalf, and on the wire the two look alike. - **Hang, then timeout:** something discarded the SYN or the host is gone. The client is retransmitting in `SYN-SENT`. - **Fast failure citing an ICMP unreachable:** an ICMP error arrived and the stack chose to act on it, even a soft one. Which operating-system messages and which inspection tools show these states is the business of the operating-system and diagnostics topics; the protocol rules above are the same everywhere, though stacks differ in retry counts and in how they act on ICMP errors.

  • Why does a TCP client in SYN-SENT accept the reset from a closed port but ignore a reset whose acknowledgment number does not match its SYN?
    RFC 9293 accepts a reset in SYN-SENT only if its ACK field acknowledges the SYN the client sent. That ties the reset to this attempt: a stale reset from an earlier connection fails the check, and a forger who never saw the SYN would have to guess the client's ISN. A failing reset is dropped and the attempt continues.
  • Is a TCP connection refusal proof that the server host is up?
    Not quite. It proves something at that address answered the SYN with a reset. Usually that is the host's own TCP with no listener on the port, but a firewall configured to reject rather than drop can send an identical RST on the host's behalf, and the wire cannot tell the two apart.
  • Should a TCP client abort a connection attempt when an ICMP Destination Unreachable that RFC 9293 classes as a soft error arrives?
    RFC 9293 classes Destination Unreachable codes 0, 1 and 5 as soft errors: the stack MUST NOT abort on them alone and SHOULD tell the application, since routing may recover while the SYN is retried. Port unreachable, code 3, is a hard error that SHOULD abort. RFC 9293 notes many implementations treat soft errors as hard during setup anyway.

saying these in an interview costs you the question

  • A closed port silently drops the SYN, so the client just times out.
  • A reset in reply to a SYN means the server application crashed.
  • A firewall that drops packets makes connect fail as fast as a closed port.
  • Any reset that arrives during SYN-SENT aborts the connection attempt.
  • Any ICMP Destination Unreachable must abort the connection attempt at once.