6.4Diagnosing app connectivity (NAT, port blocking, proxy, VPN)

As the capstone of this chapter, this section binds the earlier knowledge of L2/L3, devices/planes, and IP services/ports into the diagnostic skill of pinpointing the network factor behind a field symptom of "app/automation cannot connect." The same connection timed out can stem from a failed NAT return, firewall port blocking, not going through a corporate proxy, or a disconnected VPN—each with entirely different checks and remedies. "Do not take the error string at face value; verify the suspected network factors in order"—this section builds that pattern.

6.4.1Main network factors that stop connections

• A NAT problem: it translates internal hosts' private IPs for the outside, but if the translation-table mapping or return path breaks, packets go out yet no response returns, or only one direction works. Pitfalls include many outbound connections from one host and hairpin NAT (calling internal-to-internal via an external VIP). Symptoms: "connects sometimes / no return."
• Port blocking: a firewall/ACL/security group does not permit the required destination port (e.g. RESTCONF 443, NETCONF 830, SNMP 161). Symptoms are connection timed out (silently dropped) or connection refused (rejected with RST). If ping works but only a specific port fails, suspect this first.
• A proxy: in corporate networks, outbound HTTP/HTTPS is often permitted only via a forward proxy. If a script ignores HTTP_PROXY/HTTPS_PROXY/NO_PROXY environment variables and tries to go out directly, the boundary blocks it. A VPN connects remote users to internal resources over an encrypted tunnel; with split tunnel, only internal-bound traffic goes via the VPN and the rest goes directly, so depending on VPN state/route config the symptom "only the internal API is unreachable" can arise.