Testing Network Connectivity With Kali Linux

“It’s up, I can ping it.” That single sentence is responsible for more wasted troubleshooting hours than almost anything else in infrastructure work. A ping succeeds, so the engineer assumes the network is fine and starts restarting the application — the wrong move, at the wrong layer, before any evidence has been gathered.

In this lesson we test connectivity the way a disciplined engineer does: one layer at a time, from the bottom up, proving each layer before trusting the one above it. We will use ping, traceroute, tracepath, nc, and curl — the five tools that answer the question “how far up the stack does traffic actually get?” More importantly, you will learn to read their output as evidence, and to recognize the four failure signatures that tell you exactly which layer just broke.

What You Will Learn

• Why a successful ping proves almost nothing about your application
• The connectivity hierarchy: reachability → TCP port → TLS → HTTP → application
• Testing raw L3 reachability with ping
• Finding where packets die on the path with traceroute and tracepath
• Testing a TCP port without sending data using nc -vz
• Running a full application-layer test and reading the trace with curl -v
• The four failure signatures and what each one tells you to test next

The Connectivity Hierarchy

Here is the single most important idea in this lesson. “Connectivity” is not one thing — it is a stack of independent checks, each of which can pass or fail on its own:

ping works
  ≠ TCP port works
    ≠ TLS works
      ≠ HTTP works
        ≠ Application works

Read each ≠ as “does not prove.” Let’s walk up it.

• ping works — The host answered an ICMP echo request. This proves Layer 3 (network) reachability only: packets can travel from you to that IP address and back. It says nothing about whether any service is running, whether a port is open, or whether a firewall permits TCP.
• ≠ TCP port works — Reachability at L3 does not mean the specific port you need is open. A host can be perfectly reachable while port 443 is closed, filtered, or has nothing listening. TCP adds the transport layer: a successful connection means something completed the SYN / SYN-ACK / ACK handshake on that port.
• ≠ TLS works — An open TCP port does not mean TLS will negotiate. The certificate could be expired, the hostname could mismatch, the cipher suites could be incompatible, or the service on that port might not speak TLS at all. TLS adds encryption and identity: a working handshake proves the server presented a certificate your client accepted.
• ≠ HTTP works — A completed TLS handshake does not mean the web server will answer correctly. You can get a clean TLS session and still receive a 502 Bad Gateway, a 403, or a hang. HTTP adds the request/response protocol: a working HTTP layer means the server parsed your request and returned a status line.
• ≠ Application works — A 200 OK at the HTTP layer still does not mean your application is healthy. The response body could be an error page, the database behind it could be down, or the health endpoint could be lying. The application layer is the only one that proves the thing your users actually care about.

Every tool in this lesson tests exactly one of these rungs. The skill is knowing which rung you just proved — and refusing to assume anything about the rungs above it.

🔎 Troubleshooting Tip — Start at the lowest layer you can verify and climb. If ping fails, there is no point testing HTTP. If ping succeeds but nc to the port fails, the problem is at the port/firewall layer, not the app. Let the layers tell you where to look.

This maps directly onto the simplified troubleshooting stack we use throughout this series:

Application → TLS → Port → DNS → Gateway → Route → Interface

Diagnose top-down when you have a symptom (“the site is down”), but verify bottom-up when you test — prove Interface, Route, Gateway, and DNS before you blame the Application.

Layer 3: ping

ping sends ICMP echo requests and waits for echo replies. It is the cheapest possible test of “can packets reach this IP and come back.”

ping -c 4 example.com

The -c 4 flag sends exactly four packets and then stops, instead of running forever. Read the output like this:

64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=11.2 ms
...
4 packets transmitted, 4 received, 0% packet loss

What does this output tell us? Three things. First, DNS resolved — example.com became an IP, so name resolution worked (a free bonus, not the point of the test). Second, packets are reaching that IP and returning: 0% packet loss means clean L3 reachability. Third, time=11.2 ms is the round-trip latency, and ttl=56 hints at how many router hops away the host is (TTL counts down from a starting value like 64 as it crosses routers).

What should we test next? Nothing yet at this layer — but do not stop here. A clean ping tells you the network path exists. It tells you nothing about the port your service listens on.

Two important caveats:

• A failed ping does not prove the host is down. Many production hosts, load balancers, and cloud security groups deliberately drop ICMP. ping timing out on a firewalled host is expected, not evidence of failure. Never conclude “the server is down” from ping alone.
• A successful ping is L3 only. ICMP does not use TCP or ports. It is the classic trap: ping is green, the app is still broken.

🏭 Why This Matters in Production — Cloud load balancers and Kubernetes ingress controllers frequently answer ping at the node level while the pod behind them is crash-looping. The ICMP reply comes from the kernel; your application never sees the packet. If you page someone because “ping works so it must be the app,” you have skipped every layer that actually matters.

Finding Where Packets Die: traceroute and tracepath

When ping fails or is slow, the next question is where along the path traffic is dying. traceroute maps the sequence of routers between you and the destination by sending packets with deliberately small, increasing TTL values and recording which router sends back each “time exceeded” message.

traceroute example.com

Each numbered line is one hop — one router closer to the destination:

 1  192.168.1.1     0.6 ms   0.5 ms   0.5 ms
 2  10.0.0.1        4.1 ms   3.9 ms   4.0 ms
 7  93.184.216.34  11.4 ms  11.1 ms  11.2 ms

What does this tell us? The path is complete because the final hop is our destination IP. Three timing columns per hop are three probes — useful for spotting a flaky link. If the trace stops advancing and shows * * * for the remaining hops, packets are dying at the last responding router. That is your boundary: the problem is at or just beyond that hop (often a firewall, a missing route, or a down link).

tracepath does the same job without requiring elevated privileges, and it also discovers the path MTU:

tracepath example.com

tracepath is often the friendlier choice on a locked-down box because plain traceroute sometimes needs CAP_NET_RAW to send its probes, whereas tracepath uses UDP and works unprivileged. Its extra trick — reporting pmtu — is genuinely useful when a connection completes the handshake but then hangs on large payloads (a classic MTU/fragmentation problem that ping and a simple port test will never reveal).

🛠️ DevOps Perspective — In a VPC or overlay network, traceroute is how you tell “the route is wrong” from “the security group is blocking.” If the trace dies at your NAT gateway, that is a routing/network-ACL story. If it reaches the target host but the port is closed, that is a security-group or service story. Same symptom, two completely different fixes — the trace tells you which.

For deep path analysis and MTR (the continuously-updating combination of ping and traceroute), see Traceroute & MTR Path Analysis.

Layer 4: Testing a TCP Port With nc

This is the tool that breaks the “ping works so we’re fine” habit. nc (netcat) can open a TCP connection to a specific port and tell you whether the handshake completes — without sending a single byte of application data.

nc -vz server.example.com 443

The two flags are the whole point:

• -z means zero-I/O mode: attempt the connection, report the result, and close it immediately. It does not transmit any payload, so it is a safe, non-intrusive probe.
• -v means verbose: print the human-readable result instead of staying silent.

A successful probe looks like this:

Connection to server.example.com (93.184.216.34)
  443 port [tcp/https] succeeded!

What does this tell us? That the full TCP three-way handshake completed on port 443:

you  → SYN     → server
you  ← SYN-ACK ← server
you  → ACK     → server   (connection established)

You have now proven the next rung up from ping: a service is listening on that port and the network permits TCP to it. That is strictly more than ping proved — and strictly less than “the application works.”

What should we test next? You know the port accepts TCP. You do not know whether TLS will negotiate or whether HTTP will answer. Climb to curl.

You can also test a range or several ports at once, which is handy when verifying a service exposes exactly what you expect:

nc -vz server.example.com 80 443

🔎 Troubleshooting Tip — nc -vz is your fast disambiguator between “network problem” and “app problem.” Port succeeded but the app returns errors? The network delivered you to the door — stop blaming the firewall and go read the application logs. Port refused or timed out? Do not touch the app yet; the traffic never arrived. See Ports & Listening Services for the other side of this — confirming what is actually listening on the server.

The Full Application Test: curl -v

curl -v walks every layer for you and narrates each step. It is the closest thing to a single command that tests the entire hierarchy, which is why it belongs at the top of your toolkit.

curl -v https://server.example.com

The -v (verbose) output is a guided tour up the stack. Read it in order:

* Host server.example.com:443 was resolved.
* Trying 93.184.216.34:443...
* Connected to server.example.com (...) port 443
* TLS handshake, cert verify OK
> GET / HTTP/2
> Host: server.example.com
<
< HTTP/2 200
< content-type: text/html

Decode it layer by layer:

• Host ... was resolved — DNS worked. The name became an IP.
• Trying ...:443 then Connected — TCP worked. This is the same handshake nc proved, now inside curl.
• TLS handshake ... cert verify OK — TLS worked. The certificate validated; encryption is established. If the cert were expired or the hostname mismatched, curl stops here with a TLS error — and you have isolated the failure to the TLS layer without ever touching the app.
• Lines starting with > are your HTTP request; lines starting with < are the server’s response. HTTP/2 200 is the status line — the HTTP layer works.
• The response body (below the headers) is the application speaking. This is the only line that reflects what your users see, and even 200 OK can wrap an error page — so read the body, do not just trust the status code.

What does this give us that nc did not? Everything above the port. nc proved TCP; curl -v proves DNS, TCP, TLS, HTTP, and shows you the application response — in one command, in stack order, with the exact layer of any failure labelled in its output.

🧪 Try It — Run curl -v https://example.com and identify, line by line, where DNS ends and TCP begins, where TCP ends and TLS begins, and where the HTTP request starts. Being able to point at those boundaries in real output is the core skill of this lesson.

For failures that surface specifically at the TLS or HTTP layer, the deeper guides are TLS Certificate Troubleshooting and HTTP & API Troubleshooting.

🔐 Security Note — Only test systems you own or are explicitly authorized to assess. The examples here use example.com, a safe public endpoint reserved for documentation. Point nc, curl, and traceroute at your own lab or your own infrastructure — probing third-party hosts without permission is not troubleshooting, it is scanning someone else’s systems.

The Four Failure Signatures

Most connectivity failures announce themselves with one of four distinctive messages. Learn to read them as clues that point at a specific layer — clues, not guarantees.

Signature	Layer it implicates	Which tool surfaces it	Test next
Connection refused	Port / service	nc, curl	Is the service running and bound to that port?
Connection timeout	Firewall / route / host	nc, curl, ping	Trace the path; check firewall & security groups
No route to host	Routing / L2	ping, nc	Inspect routing table and gateway
Could not resolve host	DNS	curl, ping	Query DNS directly

Connection refused — You reached the host, and it actively rejected the port. Something sent a TCP RST: either nothing is listening on that port, the service is bound to a different interface, or a local firewall is issuing a reject (not a silent drop). This is oddly good news — the network path works. The problem is the service. Confirm what is listening with the techniques in Ports & Listening Services.

Connection timeout — Your packets left and nothing came back. No RST, no reply, just silence. This signature screams firewall drop, wrong route, or a down host — a security group, network ACL, or Kubernetes network policy silently discarding packets. Timeout means “swallowed,” refused means “rejected”; the difference tells you whether to look at the firewall (timeout) or the service (refused). Use traceroute to find where the packets disappear.

No route to host — Your own machine has no path to send the packet in the first place. This is a routing or L2 problem on your side or the immediate network: a missing default gateway, a down interface, or an unreachable subnet. Nothing left the building. Go to Linux Routing and inspect the routing table.

Could not resolve host — The name never became an IP, so no packet was ever sent anywhere. This is purely DNS. Every other layer is irrelevant until resolution succeeds. This is the subject of the next lesson, DNS Troubleshooting.

🏭 Why This Matters in Production — “Connection refused” and “Connection timeout” look equally red on a dashboard, but they send you to opposite teams. Refused → the app or service owner. Timeout → the network, firewall, or platform team. Reading the signature correctly is the difference between a five-minute fix and an hour of the wrong people staring at healthy logs.

Try It Yourself

Work up the hierarchy against a safe target and watch each rung report independently.

1. L3: ping -c 4 example.com — confirm reachability and note the latency and TTL.
2. Path: tracepath example.com — count the hops and note the path MTU.
3. L4: nc -vz example.com 443 — prove the TCP port accepts a handshake, with no data sent.
4. Full stack: curl -v https://example.com — label every line as DNS, TCP, TLS, HTTP, or application.
5. Break it on purpose: nc -vz example.com 444 (a port with nothing listening) and curl -v https://thisdomaindoesnotexist.invalid — produce a timeout/refused and a resolution failure, and match each to its signature above.

The goal is not to memorize commands. It is to internalize the reflex: prove the layer below before you trust the layer above.

Common Problems

• “Ping works, so the app is fine.” Ping is L3 only. Always climb to nc (port) and curl (application) before declaring anything healthy.
• “Ping fails, so the host is down.” Many hosts drop ICMP by policy. Test the actual TCP port with nc before concluding the host is unreachable.
• Restarting the app first. If nc shows the port refusing or timing out, the traffic never reached a working listener — restarting the app blindly wastes a maintenance window. Diagnose the layer first.
• Ignoring the difference between refused and timeout. They point at different teams and different fixes. Read the exact word.
• Trusting 200 OK. A 200 at the HTTP layer can still wrap an application error page. Read the response body, not just the status line.

Troubleshooting Workflow

When a service is unreachable, verify from the bottom up and stop the moment a layer fails — that layer is your problem.

1. ping / tracepath  → Is L3 reachable? Where does the path die?
2. (resolve)         → Did the name become an IP? (curl/ping report this)
3. nc -vz host port  → Does the TCP port accept a handshake?
4. curl -v https://  → Do TLS, HTTP, and the app respond?
5. Match the failure signature → route the fix to the right layer.

Never start at step 4 with “restart the app.” Start at the lowest layer you can verify and climb. The first layer that fails is the layer to fix — and everything above it is a distraction until it does.

What You Learned

• A successful ping proves L3 reachability only — it never proves a port, TLS, HTTP, or the application works.
• The connectivity hierarchy is a stack of independent checks: ping ≠ TCP ≠ TLS ≠ HTTP ≠ application, and each tool tests one rung.
• ping -c 4 tests reachability; traceroute and tracepath show where packets die (and tracepath runs unprivileged and reports path MTU).
• nc -vz host port proves a TCP handshake with zero data sent — the fast way to separate a network problem from an app problem.
• curl -v narrates the entire stack — DNS, TCP, TLS, HTTP, application — and labels the exact layer of any failure.
• The four failure signatures — refused (port/service), timeout (firewall/route/host), no route to host (routing/L2), could not resolve host (DNS) — each point at a specific layer and a specific next test.
• Verify bottom-up and never restart the app first; diagnose the layer, then fix the layer.

You have now proven, or ruled out, every layer except the one that quietly breaks most often: name resolution. When curl says could not resolve host, every tool above is useless until DNS is fixed. That is exactly where we go next — Part 9: DNS Troubleshooting.