criticalIntermediateSymptom-first#firewall#syn#timeout#iptables#packet-drop

TCP connect timeout -- firewall silently dropping SYN packets

curl: Connection timed out after 30-120s instead of refused

Likely source:connectivityavailability

Focused incident mode — strips away everything but this runbook.

Symptoms

  • curl: Connection timed out after 30-120s instead of refused
  • nc -zv <host> <port> hangs with no response (no RST, no SYN-ACK)
  • tcpdump shows SYN sent but no SYN-ACK or RST returned

A silent drop (no RST) vs a REJECT (RST returned) is the critical distinction. The former means a firewall is blocking, the latter means nothing is listening. Use tcpdump first.

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Packet capture at the client

    tcpdump -i any host <SERVER> -c 20

  • Firewall rules on the path

    iptables -L -n -v | head -30

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • iptables -L shows a DROP rule for the target port
  • tcpdump confirms SYN sent, no SYN-ACK or RST

Confirm before fixing

iptables -L INPUT -n -v | grep -E '<PORT>|<SUBNET>'
READ

Check the INPUT chain for a DROP or REJECT rule

Fix

iptables -I INPUT -p tcp --dport <PORT> -s <SOURCE_SUBNET> -j ACCEPT
CHANGE

Insert an ACCEPT rule before the DROP rule

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
tcpdump -i any host <SERVER> -c 20 -nn
READ

Capture to confirm the silent drop pattern

2
nc -zv <SERVER> <PORT> -w5
READ

Confirm the timeout with netcat

3
iptables -L INPUT -n -v | grep -E '<PORT>|<SUBNET>'
READ

Check local firewall for drop rules

4
iptables -I INPUT -p tcp --dport <PORT> -s <SOURCE> -j ACCEPT
CHANGE

Insert ACCEPT rule if a DROP is found

Prevention

  • Default firewall policy should REJECT, not DROP -- REJECT fails fast and is easier to debug.
  • Use infrastructure-as-code for security groups and iptables rules.
  • Add firewall rule documentation as a runbook per service.
  • Alert on connection timeout latency from client-side SYN metrics.

Related runbooks

Same stack, same failure family — worth a skim.

Firewall rule order -- REJECT/DROP rule before ACCEPT causes unexpected blockscritical

Connections to a specific port fail despite an ACCEPT rule existing for the source

NetworkingIntermediate3 causes
Open runbook
conntrack table full -- nf_conntrack: table full, dropping packetcritical

dmesg shows 'nf_conntrack: table full, dropping packet'

NetworkingAdvancedUSE3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.