Diagnosing Application Connectivity Issues

Mental model

Cisco objective 6.8 says “Diagnose application connectivity issues (NAT problem, Transport Port blocked, proxy, and VPN)”. Four classic suspects, each with its own fingerprint.

Diagnostic flow, always the same shape:

1. Can the client reach the host? ping <host> or tcping <host>.
2. Can the client reach the port? telnet <host> <port> or nc -zv <host> <port>.
3. Does the app-level request work? curl -v https://<host>:<port>/<path>.
4. Read the error — it names the layer.

Each layer failure points at a different suspect.

Suspect 1: NAT problem

Symptoms

• Client traffic reaches the server but return traffic never comes back.
• Works from one source IP, not another.
• Works briefly, then stops (NAT translation timed out).
• Server logs show a connection from an unexpected source IP (the NAT router’s outside IP, not the real client).

Why

NAT rewrites source IP / port on the way out. If translations are missing, pointed wrong, or exhausted, return traffic has nowhere to go.

Common NAT fault modes:

• One-way translation. Policy maps outbound but there is no return mapping.
• PAT port exhaustion. All 64k source ports in use; new connections fail.
• Hairpin NAT needed but not configured (internal client trying to reach the external IP of an internal server).
• NAT timeout too short for long-lived TCP connections (default often 24h, UDP much shorter).

Fix path

• show ip nat translations on the router.
• Confirm the translation exists and points at the right internal IP.
• Verify return traffic hits the same NAT box (asymmetric routing kills NAT).

Suspect 2: Transport port blocked

Symptoms

• ping <host> succeeds (ICMP works).
• telnet <host> <port> hangs or “connection refused” / “connection timed out”.
• Error message is specifically about the port.

Why

A firewall (host, perimeter, cloud security group) is blocking the TCP/UDP port.

• “Connection refused” = packet reached the host, but nothing listens (or local firewall actively RSTed).
• “Connection timed out” = packet got silently dropped. More typical of a firewall.

Fix path

• Confirm which firewall is in the path (traceroute helps).
• Check the firewall rules for the specific port.
• Verify the destination service is listening: ss -tlnp | grep :<port> on the server.
• Cloud security groups + NACLs + host firewall + corporate firewall — all four can conspire. Check each.

Suspect 3: Proxy

Symptoms

• Browser works, scripts do not (browser knows the proxy; script does not).
• Error: “proxy authentication required” (407), “SSL certificate problem”, “unable to resolve host”.
• Works from laptop on home Wi-Fi, breaks on corporate Wi-Fi.

Why

Corporate networks often route HTTPS through a forward proxy. The proxy terminates the TLS and re-signs with a corporate CA. Scripts that don’t trust the corporate CA or don’t know the proxy fail.

Fix path

• Check env vars: HTTP_PROXY, HTTPS_PROXY, NO_PROXY.
• Point your tool at the right proxy: curl -x http://proxy.example.com:3128 ....
• For scripts: requests.get(url, proxies={"http": "...", "https": "..."}).
• For the TLS cert issue: install the corporate CA in your trust store.

Suspect 4: VPN

Symptoms

• Works at the office, breaks on VPN.
• Works on VPN, breaks when disconnected.
• Partial: some corporate sites work, some do not (split tunnel).

Why

VPN inserts a tunnel. Traffic goes through a different gateway, often with different firewall rules, different DNS, different source IP.

Common fault modes:

• Split-tunnel misconfig. Only certain subnets go through the VPN; the destination is not in that list.
• DNS inside vs outside. VPN hands you a corporate DNS server; the destination name may resolve differently.
• MTU issues. VPN encapsulation reduces usable MTU; large packets get fragmented or dropped.
• Route conflict. VPN pushes a route that overlaps with your local LAN.

Fix path

• ip route / route print — is there a route to the destination via the VPN?
• nslookup <host> — are you resolving via the right DNS?
• Try ping <host> with smaller MTU: ping -M do -s 1400 <host> on Linux.

Diagnostic order (quick reference)

┌─────────────────────────┐
│ ping <host>             │  works? → network path OK (or ICMP allowed)
├─────────────────────────┤  fails? → suspect routing / NAT / network down
│ traceroute <host>       │  shows last reachable hop
├─────────────────────────┤
│ nc -zv <host> <port>    │  works? → port is reachable
├─────────────────────────┤  fails? → suspect firewall / port blocked
│ curl -v https://...     │  works? → app issue, not network
└─────────────────────────┘  fails with cert error? → proxy / cert
                              fails with 4xx/5xx? → app-level problem

Reading the error

FAQ

Why does ping succeed but the browser fail? Ping is ICMP; the app runs over TCP on a specific port. Firewalls commonly allow ICMP but block random TCP ports. Check the port.

My corporate VPN gives slow Internet when connected. Full tunnel mode: ALL traffic goes through corporate HQ before heading out. Split tunnel is faster but exposes you to the normal Internet directly for non-corporate hosts.

Should I disable the firewall to “test”? Only on a dev machine, briefly. Never on a production server. Instead: open the specific port in a tight scope.

I see a lot of connections to the proxy’s IP in my netstat. Normal? Yes if your HTTP/HTTPS traffic routes through a proxy — every request to any external site shows up as “connect to proxy”.