# A Connectivity Troubleshooting Checklist — Cloud Networking: VPCs, Subnets & Peering

Source: https://www.skillbyai.com/en/cloud-networking/cn-troubleshooting

> Diagnose 'cannot connect' problems layer by layer instead of guessing.

## Work the path hop by hop

When A cannot reach B, guessing wastes hours. Walk the path in order and verify each layer. **1. DNS:** does the name resolve, and to the address you expect (private versus public)? **2. Routing at the source:** does A's subnet route table have a route to B's address, and is the target correct? **3. Routing back:** does B's route table have a route to A? Missing return routes are common across peering and VPNs. **4. NACLs** on both subnets, in both directions, including ephemeral ports. **5. Security groups:** B's inbound rule must allow A's port and source; A's outbound must allow the destination. **6. The host:** is the service actually listening on that port and interface, and is an OS firewall blocking it? Tools help: flow logs show REJECTs, and AWS **Reachability Analyzer** statically checks the configuration path between two resources and names the blocking component. Change one thing at a time and re-test.

## Host-side checks

Run these on the destination and source hosts. The DNS step and the 'is it listening' step catch a surprising share of problems.

```bash
# On the client: does the name resolve to the private IP you expect?
dig +short db.internal.example.com

# On the client: can a TCP connection be opened? (-z scan only, -v verbose, -w timeout)
nc -zv -w 3 10.0.2.40 5432

# On the server: is anything listening on 5432, and on which address?
sudo ss -ltnp | grep 5432
```

## Tracing a missing parcel

If a parcel does not arrive, you check the address label, the sorting centre, the delivery van and finally whether anyone was home. Skipping straight to blaming the courier rarely finds the real cause.

## Timeout versus refused

A connection *refused* quickly usually means the packet arrived and nothing is listening. A *timeout* usually means a firewall or route silently dropped it. That single observation tells you which half of the checklist to start with.

**Quiz:** nc to 10.0.2.40:5432 returns 'Connection refused' immediately. Where should you look first?

- [x] Whether the service is listening on that port on the server
- [ ] The VPC peering routes
- [ ] The internet gateway
- [ ] The NAT gateway's Elastic IP

*Answer:* Whether the service is listening on that port on the server. A fast refusal means the packet reached the host, which replied with a reset. The path is fine; the service or host firewall is the problem.