criticalIntermediateSymptom-first#firewall#iptables#nftables#rule-order#chain

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

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

Likely source:configurationconnectivity

Focused incident mode — strips away everything but this runbook.

Symptoms

  • Connections to a specific port fail despite an ACCEPT rule existing for the source
  • iptables -L shows the ACCEPT rule but it is below a DROP/REJECT rule in the chain
  • Adding a new firewall rule broke existing connectivity for unrelated services

iptables -A appends to the end of the chain; always use -I to insert at the correct position. Modern nftables uses priority-based ordering instead of linear chain traversal.

Evidence to grab

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

  • Full iptables chain with rule numbers

    iptables -L -n -v --line-numbers

  • nftables ruleset

    nft list ruleset

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 at line 5 and an ACCEPT at line 15 for the same port
  • Connections from the accepted source are being dropped

Confirm before fixing

iptables -L INPUT -n -v --line-numbers | grep -E 'DROP|REJECT'
READ

List all blocking rules with their line numbers

Fix

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

Insert the ACCEPT rule at the top of the chain (before the DROP)

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
iptables -L INPUT -n -v --line-numbers
READ

List all rules with line numbers

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

Insert ACCEPT rule before the blocking rule

3
iptables -L INPUT -n -v --line-numbers | head -10
READ

Verify the rule order after the fix

Prevention

  • Use iptables -I (insert) instead of -A (append) when adding rules to avoid ordering issues.
  • Document firewall rule ordering and test changes in a staging environment first.
  • Use infrastructure-as-code (Terraform, Ansible) for firewall rules to maintain consistent ordering.
  • Set up firewall rule change monitoring to detect when rules are added in the wrong position.

Related runbooks

Same stack, same failure family — worth a skim.

TCP connect timeout -- firewall silently dropping SYN packetscritical

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

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.