~/tutorials/028-answers-but-no-connection.md

028: Answers but no connection

A host that answers ping and refuses every connection is the most common strange thing on any network, and the diagnosis is almost never exotic. This is the lesson where you stop reading a scan as a verdict and start reading it as an interview, because "up but unreachable" is three different stories wearing one symptom.

The three stories

A firewall is declining on your behalf. The host is alive, healthy, and its firewall is dropping or rejecting your packets before any service sees them. Nothing is wrong with the machine. Something is right with its boundaries, and from outside, health and hostility look identical.

The service is not listening. The host answers ping because answering ping is the kernel's job. The port refuses because no process claimed it, and the daemon you expected is down, crashed, or was never installed. The host is fine and the service is the finding.

The host is half-dead. Kernel alive, userspace wedged: ping answered by the kernel, everything else unanswered because the userspace that would answer is gone. The rarest of the three, the one that looks like the other two for hours, and the one that teaches why "up" is a weaker word than it sounds.

Reading the refusal properly

Lesson four drew the line between closed and filtered, and this is where that line earns its keep. A closed port sent you an honest refusal: the host is running IP just fine and no service is there. A filtered port sent you nothing: something between you and the service swallowed the packet, and that something is usually a wall you should name in the report. Collapsing both into "does not work" throws away the only fact the scan produced.

nmap -sV 127.0.0.1 | grep closed

Not shown: 997 closed tcp ports (reset)

reset is the tell: 997 doors answered "no" loudly. A host whose missing ports were filtered would show them as filtered instead, and the scan would say so. Same count of unavailable doors, completely different story about who is refusing and why.

The ladder you run at home

The snapshot cannot demonstrate a half-open host, so this is the at-home shape: ping it, then try the one port you know should answer, then check from another machine on the same segment, then check from the host itself. Each step eliminates a story. Ping plus no connection plus a healthy port from localhost is the firewall. Ping plus no connection plus nothing from localhost is the service or the host, and ssh depth sorts those two in one command.

The order matters because each rung is cheap and the expensive guess, "it must be down, reboot it", is what the ladder exists to prevent. A wedged service behind a reboot loses its evidence, and the post-mortem starts with you having destroyed the scene.

Try it

Each of these has one answer, and the shell gives it to you. Check yourself.

1. Read the accounting line above. What exactly did 997 doors do, and what would the line say if a wall had eaten the probes instead?
2. Say the three stories in your own words, one sentence each, without looking. If you can say them, you can diagnose them.
3. Ping answers, port 22 refuses with reset. Which stories just died, and which survive?
4. Ping answers, port 22 filtered. Now which survive? Write the next two commands you would run, in order, and say what each eliminates.

This host is a snapshot and always answers the same. Your hosts at home are the real exercise, and the ladder is the deliverable.