Diagnosing Connectivity Issues

Cloud Troubleshooting & Support

Chapter 2 · Diagnosing Connectivity Issues

"I can't connect to X" is probably the single most common category of real cloud support ticket. cloud1-5 ended with a practical checklist — security group → NACL → route table → DNS. This chapter turns that checklist into a genuine, actionable flowchart.

Step 0 — Reproduce and Scope the Problem First

Before touching any configuration: confirm exactly what's failing — which specific connection, from where, to where, and what error is actually observed. "It doesn't work" isn't enough information to act on. Timeout, connection refused, and DNS resolution failure are three genuinely different categories of problem, and distinguishing between them immediately narrows the investigation before checking a single config setting.

Distinguishing Failure Types

Failure type	What it means
Connection refused	Something on the network path is reachable and actively rejecting the connection — often nothing is listening on that port, or an explicit reject rule exists
Connection timeout	No response at all — packets are being silently dropped, typically by a security group, NACL, or missing route (cloud firewalls usually drop rather than reject)
DNS resolution failure	The hostname never resolved to an IP at all — a completely different problem category, never even reaching the network layer

This distinction alone is the fastest triage step in this entire chapter

Refused vs. timeout vs. DNS failure narrows down which of cloud1-5's four checklist layers is actually at fault before checking anything else — a DNS failure means the network layer was never even reached; a timeout points strongly at a silent drop (security group/NACL/route table); a refused connection points at something listening but rejecting, or nothing listening at all.

Working Through Security Groups

Check inbound rules on the destination for the correct port, protocol, and source. A genuinely common gotcha: fixating on the destination's security group while forgetting the source resource — if traffic originates from another VM or service inside the same VPC, that source resource's own outbound rules may also need to explicitly permit the connection.

Working Through NACLs

Revisiting cloud1-5's stateless nuance in practice: check both inbound and outbound NACL rules explicitly, remembering the ephemeral port range needed for return traffic, since NACLs track nothing about the connection itself. A concrete, genuinely common mistake: allowing inbound port 443, but forgetting to allow the outbound ephemeral port range (typically 1024-65535) the response needs to actually leave on.

Working Through Route Tables

Confirm the subnet's route table actually has a route to wherever the traffic needs to go — an internet gateway for public traffic, a NAT gateway for private-subnet outbound, or a VPC peering connection/transit gateway for cross-VPC traffic (cloud1-5).

VPC peering needs routes on both sides

A route existing in one direction but not verified for the return path is a genuinely common real mistake, especially with VPC peering specifically — both VPCs need a route pointing at the peering connection, not just the one that initiated it. A route configured on only one side produces exactly the "traffic flows one way but not the other" symptom.

Working Through DNS

Confirm the hostname resolves to the IP actually expected, using tools like nslookup/dig. A genuinely common trap: DNS caching (cloud1-8's TTL material) meaning a stale, outdated IP is still being returned locally, even though the DNS record itself was already correctly updated. Also worth checking: is this internal DNS (service discovery within a VPC) or external/public DNS (cloud1-5) — the two follow genuinely different resolution paths.

Putting It Together — The Full Flowchart

REPRODUCE & SCOPE   -- what, from where, to where, what error exactly
CLASSIFY THE FAILURE TYPE   -- refused / timeout / DNS failure
3a. If DNS failure  -> check resolution, TTL/caching, internal vs. external DNS
3b. If refused/timeout  -> check security groups (BOTH source and destination)
Check NACLs   -- both directions, remember ephemeral ports
Check route tables   -- both directions if cross-VPC/peered
If everything above passes  -> confirm the application itself is actually running and listening on the expected port

That last step closes the loop deliberately: the network path can be entirely correct while nothing is actually listening on the other end — a genuinely common final culprit once every network-layer check has passed clean.

Hands-On Exercises

Exercise 1

A user reports "connection refused" (not a timeout) trying to reach a service on port 8080. Given this chapter's failure-type distinction, what does this specific error type suggest is not the problem, and what should be checked instead?

📄 View solution

Exercise 2

Walk through the specific NACL gotcha of allowing inbound port 443 but forgetting the outbound ephemeral port range. Explain exactly what a user would observe as a result, and why.

📄 View solution

Exercise 3

Two VPCs are peered, but traffic only flows in one direction. Using this chapter's route table material, explain the likely cause.

📄 View solution

Chapter 2 Quick Reference

Refused (something's listening, actively rejecting) vs. timeout (silent drop, likely SG/NACL/route) vs. DNS failure (never reached the network layer) — the fastest triage step in this chapter
Security groups: check both the source's outbound and the destination's inbound rules
NACLs: stateless — check both directions explicitly, including the ephemeral port range for return traffic
Route tables: VPC peering needs a route configured on both sides, not just the initiator
DNS: check for stale cached answers (TTL, cloud1-8) and confirm internal vs. external resolution path
Full flowchart: reproduce/scope → classify failure type → security groups → NACLs → route tables → confirm the application is actually listening
Next chapter: IAM & Permission Troubleshooting — reading and debugging policy errors, "access denied" causes