1. Firewalls or ACLs Blocking Specific Ports

Ping (ICMP) is allowed
TCP/UDP ports are blocked

This is the #1 reason apps fail when ping works.

You might be trying to access:

• • • An RDP server (port 3389)
    • A web app (port 80 or 443)
    • A database (port 1433, 3306, etc.)

If a firewall or ACL blocks that specific port, the app fails — but ping still goes through.

What to check:

• • • Firewalls (Windows firewall, network firewalls)
    • Router ACLs (inbound/outbound)
    • Cloud security groups (AWS, Azure, GCP)
    • Local OS firewall

show access-lists

telnet <server> <port>   ← Quick port check (for TCP)

2. Application Is Listening on a Different Port or Interface

You try to access a service on its “usual” port — say, SSH on port 22 — but it fails.

Why?

The service might be listening on a non-standard port, or on localhost only.

Example:

• • • Web server running on port 8080 instead of 80
    • Application bound to 127.0.0.1 instead of the actual IP

How to check:

On Linux:

sudo netstat -tulnp

On Windows:

netstat -an | findstr LISTENING

Make sure the app is:

• • • Running
    • Listening on the correct port
    • Bound to the right interface

3. DNS Resolution Issues

Yes — DNS can break your app while ping still works.

If your app uses a hostname, but DNS fails, the app won’t resolve the IP — even though ping 10.1.1.1 works fine.

ICMP uses IP. Your app likely uses hostnames.

Test it:

ping google.com   ← If this fails, DNS issue

nslookup <hostname>

Add a fallback:

ip name-server 8.8.8.8

4. NAT Is Misconfigured (Especially in Internet Access or VPNs)

Let’s say:

• • • You ping a public IP — it works
    • You try to access a web page — nothing happens

Sounds like routing is okay, but the app fails.

Now suspect NAT.

Without correct NAT, your traffic might go out, but the replies won’t know how to get back.

This happens with:

• • • Misconfigured PAT
    • Missing NAT rules for a subnet
    • VPN tunnels without NAT exemption

What to check:

show ip nat translations

show run | include ip nat

Make sure:

• • • Inside/outside NAT interfaces are configured
    • NAT rules exist for your subnet
    • NAT overload (PAT) is working properly

5. Asymmetric Routing or Missing Return Path

Ping uses small, stateless packets. Applications use larger, connection-based traffic.

Sometimes:

• • • Your request reaches the server
    • But the reply takes a different route, and gets dropped by firewalls or routers

It’s like talking to someone on the phone, but their reply goes to your neighbor.

How to detect:

• • • Use traceroute and reverse traceroute (if available)
    • Compare path to and from destination
    • Inspect firewall logs for asymmetric traffic drops

Fixing it may require:

• • • Static routes
    • Policy-based routing
    • NAT exemptions

6. MTU or Fragmentation Issues

Ping uses tiny packets. Applications (like file transfers, VPN, HTTPS) use large ones.

If:

• • • Path MTU is smaller than expected
    • And DF (Don’t Fragment) bit is set
    • Routers or firewalls can’t fragment the packet…

Large packets will be silently dropped.

Detect with:

ping <ip> size 1500 df-bit

If that fails but smaller sizes work — bingo! MTU problem.

7. Application-Specific Protocol or TLS Issues

Some apps fail after reaching the destination, due to:

• • • TLS handshake errors
    • Certificate issues
    • App-layer protocol mismatches
    • Authentication timeouts

Example:

• • • HTTPS fails due to expired certificate
    • SSH hangs because of unsupported algorithm

Ping has no idea about these — it’s just sending echo requests.

 Fix:

• • • Use app-level debuggers
    • Wireshark or tcpdump

Logs from the application server