The Troubleshooting Handbook: Real-World Scenarios

Theory is comfortable. Troubleshooting is not. The PCNE exam does not just test whether you know what a firewall rule is—it tests whether you can diagnose why a specific connection is failing when five different components are involved. This article presents the most common real-world troubleshooting scenarios you will encounter, both on the exam and in production. For each scenario, we walk through the symptoms, the likely cause, and the diagnostic path.

Scenario 1: “I Can’t SSH Into My VM”
Symptoms

You run gcloud compute ssh my-vm and it times out.

Diagnostic Path
  1. Does the VM have a public IP? If not, are you using IAP? If neither, SSH cannot work.
  2. Is there a firewall rule allowing TCP 22? If using IAP, the source range must be 35.235.240.0/20. If using a public IP, the source must include your client IP.
  3. Check the firewall evaluation order: Is a Hierarchical Policy at the Org or Folder level denying SSH before your VPC rule can allow it?
  4. Check the VM’s network tags or service account: Does the firewall rule’s target match the VM’s identity?
  5. Run a Connectivity Test: In Network Intelligence Center, specify the source as your IP and the destination as the VM on port 22. The test will pinpoint the exact rule or route that blocks the packet.

90% of “I can’t SSH” problems are firewall misconfigurations. Always start there.

Scenario 2: “My Load Balancer Shows All Backends Unhealthy”
Symptoms

The Global HTTPS LB returns 502 errors. The backend health status in the Console shows all instances as “UNHEALTHY.”

Diagnostic Path
  1. Did you allow the health check source ranges? Health check probes come from 35.191.0.0/16 and 130.211.0.0/22. These must be allowed in your firewall rules for the health check port.
  2. Is the health check port correct? If your app runs on port 8080 but the health check is configured for port 80, it will always fail.
  3. Is the health check path correct? If the health check path is /health but your app returns 404 on that path, the backend is marked unhealthy.
  4. Is the backend in the correct network? If the backend is in a different VPC than the load balancer expects, the health check probes cannot reach it.
Scenario 3: “Traffic Between Peered VPCs Is Not Working”
Symptoms

VM A in VPC-1 cannot ping VM B in VPC-2, even though VPC Peering is configured.

Diagnostic Path
  1. Is the Peering connection ACTIVE on both sides? Peering requires both sides to create the peering link. If only one side has configured it, it is in INACTIVE state.
  2. Are the CIDR ranges overlapping? If VPC-1’s subnet 10.0.0.0/16 overlaps with VPC-2’s 10.0.0.0/16, peering cannot be established.
  3. Do firewall rules allow the traffic? Peering does not automatically open firewalls. The ingress rules in the destination VPC must allow traffic from the source VPC’s IP range.
  4. Are custom routes being exchanged? By default, only subnet routes are exchanged. If you use custom static or dynamic routes, you must explicitly enable --import-custom-routes and --export-custom-routes on the peering connection.
Scenario 4: “My VPN Tunnel Keeps Flapping”
Symptoms

The VPN tunnel status alternates between ESTABLISHED and NO_INCOMING_PACKETS every few minutes.

Diagnostic Path
  1. MTU mismatch: IPsec adds overhead to every packet. If your on-prem router’s MTU is 1500 and the tunnel MTU is 1460, large packets are dropped. Set the VM’s MTU to 1460 or enable MSS Clamping on your on-prem router.
  2. IKE version mismatch: HA VPN supports IKEv2. If your on-prem device is configured for IKEv1, the negotiation fails silently.
  3. Dead Peer Detection (DPD) interval: If your on-prem router’s DPD interval is too aggressive (e.g., 5 seconds), it may tear down the tunnel during brief network blips.
  4. Enable BFD: If the tunnel is functionally up but BGP is slow to reconverge, enabling BFD on the Cloud Router BGP session will detect failures in milliseconds, not minutes.
Scenario 5: “Cloud NAT Connections Are Randomly Failing”
Symptoms

Private VMs intermittently fail to connect to external APIs. Some curl requests succeed, others time out.

Diagnostic Path
  1. Port exhaustion. Check Cloud NAT logs for OUT_OF_RESOURCES. Increase minimum ports per VM or add more NAT external IPs.
  2. Is Dynamic Port Allocation enabled? If not, each VM is statically allocated 64 ports regardless of usage. Enable DPA to let busy VMs borrow ports from idle ones.
  3. Are all NAT IPs healthy? If one of the NAT external IPs is blacklisted by the destination service, connections through that IP will fail while others succeed.
Putting it Together: A Pro-Engineer View

Troubleshooting is a skill, not a checklist. But it follows a pattern: start with the firewall, check the route, validate the health check, and inspect the logs. The tools—Connectivity Tests, Flow Logs, Firewall Insights—exist to replace guesswork with evidence. In every scenario above, the answer was discoverable without SSHing into a single machine. That is the Google Cloud way.

Related Posts