Network Troubleshooting: 6 Essential Checks

🔥 “Just open the port!” is not a troubleshooting strategy. If an application cannot connect to a server or a service is unreachable, opening a firewall port might not fix anything. The real problem could be DNS resolution, routing, a stopped service, an incorrect listening address, or a firewall rule.
Before changing firewall settings, run these six checks to identify where the connection is failing. These commands work well for common Windows and Linux troubleshooting scenarios.

---

1. 🌐 Check DNS Resolution​

First, confirm that the hostname resolves to the correct IP address. If DNS points to the wrong server, testing firewall rules won't solve the underlying problem.
Run this command on Windows or Linux:

nslookup app.company.local

What to look for:

• ✅ Correct IP address: The hostname resolves to the expected server.
• ❌ Non-existent domain: The DNS server could not find a matching record in the queried DNS namespace.
• ⚠️ Incorrect IP address: Check the DNS records, search suffixes, and which DNS server the client is using.

If the hostname resolves incorrectly, verify the relevant DNS record and confirm that the client is querying the intended DNS server.
💡 Tip: If connecting by IP address works but connecting by hostname fails, investigate DNS and name resolution before changing firewall rules.

---

2. 📡 Test Basic Network Connectivity​

Next, check whether the destination responds to ICMP echo requests.

ping 192.168.1.10

How to interpret the result:

• ✅ Reply from: The destination, or a device responding on its behalf, returned an ICMP echo reply.
• ❌ Request timed out: No reply arrived before the timeout.
• ⚠️ Destination host unreachable: The reporting device or an intermediate router indicates that the destination cannot be reached through the attempted path.

A failed ping does not necessarily mean the server is offline. Firewalls and network devices may block ICMP while allowing application traffic over TCP.
Likewise, a successful ping does not prove that the application port is reachable.
Use this test as an initial connectivity check, not as the final diagnosis.

---

3. 🔌 Test the Specific TCP Port​

If DNS and basic connectivity look reasonable, test the actual port used by the application.
For example, HTTPS commonly uses TCP port 443.
On Windows PowerShell:

Test-NetConnection 192.168.1.10 -Port 443

On Linux, if Netcat is installed:

nc -zv 192.168.1.10 443

What the results mean:

• ✅ TcpTestSucceeded: True or a successful connection message: The TCP connection was established.
• ❌ TcpTestSucceeded: False or a timeout: The TCP connection could not be established. Investigate the network path, firewall rules, and destination service.
• ⚠️ Connection refused: The destination or an intermediate device actively rejected the connection. A missing listener or an explicit reject rule is a common cause.

A successful TCP test confirms connectivity to that port at the time of testing. It does not prove that the application is healthy, that TLS negotiation will succeed, or that authentication will work.
If the connection times out, check both directions of the connection. The request might reach the server while the response is blocked on its way back.

---

4. 🧭 Check Routing and the Network Path​

A connection can fail even when the destination server is running and the firewall allows the required port. The client may have an incorrect route, an unavailable gateway, or a routing problem between networks.
On Windows, inspect the route table:

route print

To trace the path toward the destination, run:

tracert 192.168.1.10

On Linux, inspect the selected route:

ip route get 192.168.1.10

To trace the network path, if traceroute is installed:

traceroute 192.168.1.10

Look for these signs:

• ✅ A suitable route exists: The client has a route it can use to send traffic toward the destination.
• ❌ Network is unreachable: The system cannot find a usable route for the destination.
• ⚠️ Repeated * * * in traceroute: Some hops did not return the expected probe responses. This can result from filtering or rate limiting and does not, by itself, prove that the route is broken.

💡 Important: A route on the client is only part of the picture. The server or its gateway must also have a valid return path to the client's source IP address.
If the client is on a different subnet, verify the default gateway, relevant static routes, and any routing policies between the networks.

---

5. ⚙️ Verify That the Service Is Listening​

A firewall rule cannot make an application accept connections if the application is stopped or listening on the wrong port.
Check the destination server itself.
On Windows PowerShell:

Get-NetTCPConnection -State Listen -LocalPort 443

On Linux:

ss -lntp | grep ':443'

The Linux command filters the output for text matching :443. For a more precise check, inspect the complete ss output and verify the local address and port.
Interpret the results:

• ✅ A listening socket appears: A process is listening on the matching local address and port.
• ❌ No matching result: No listener matched the query. Confirm that the service is running, using TCP, and configured for the expected port.
• ⚠️ The service listens only on 127.0.0.1: It accepts connections through the local loopback interface, not directly through the server's external network interface.

For example, a service listening on 0.0.0.0:443 generally accepts IPv4 connections addressed to the server's local IPv4 interfaces on port 443. A service listening on a specific private IP accepts connections through that address.
IPv6 listeners, wildcard addresses, and platform-specific socket behavior can differ, so inspect the actual listening address rather than assuming every listener is externally reachable.
Also verify the application's configuration and logs if the expected listener is missing.

---

6. 🛡️ Inspect Firewall and ACL Logs​

Only after checking name resolution, routing, port connectivity, and the service should you narrow the investigation to firewall policies and access control lists (ACLs).
Review the logs on the relevant host firewall, network firewall, router, or cloud security control.
Look for:

• Source IP address
• Destination IP address
• Destination port
• Protocol, such as TCP
• Timestamp of the failed connection
• Matching rule or policy action

How to interpret the entries:

• ✅ Allow or Accept: The device allowed the traffic at the point where the event was recorded. This does not guarantee that every device along the path allows it.
• ❌ Deny or Drop: A policy blocked the traffic at that point. Identify the matching rule and determine whether the block is intentional.
• ⚠️ No matching log entry: This does not prove the firewall is innocent. Logging may be disabled, the event may not be recorded, or the traffic may never have reached that device.

If a firewall rule needs to change, allow only the required source, destination, protocol, and port. Avoid disabling the firewall or opening a port to every source just to see whether the application starts working.

---

🔍 A Quick Troubleshooting Reference​

Symptom	What to investigate first
Hostname fails to resolve	DNS records and DNS server
Ping fails but TCP works	ICMP filtering; application connectivity may be fine
TCP connection times out	Routing, packet filtering, return path, or unavailable destination
Connection is refused	Listening service or an explicit reject rule
Service listens only on loopback	Service bind address
TCP connects but the application fails	TLS, authentication, application configuration, or application logs
Firewall records a deny action	Matching rule, policy scope, and intended access

🧠 The Golden Rule​

Test → Analyze → Locate the failure → Change only what is necessary.
Not every connection failure is caused by a closed port. DNS, routing, return traffic, service configuration, TLS, and authentication can all cause an application to fail.
Follow the evidence before changing the firewall. It makes troubleshooting faster, reduces unnecessary security changes, and helps you find the actual cause instead of masking the symptom.

---

Frequently Asked Questions​

------------------

Does a failed ping mean the server is down?​

No. ICMP may be blocked even when the server is online and accepting TCP connections. Test the actual application port separately.

What does a TCP connection timeout mean?​

It means the connection was not established before the timeout. Possible causes include packet filtering, routing problems, an unavailable destination, or a missing return path. A timeout alone does not identify the exact cause.

What is the difference between connection refused and connection timed out?​

A refusal indicates that the connection was actively rejected. A timeout means no successful connection was established within the allowed time. Both require further investigation to identify the underlying cause.

Should I open the firewall port if the application is not working?​

Not automatically. First confirm the destination IP, route, listening service, and relevant firewall logs. Change the firewall only when the evidence indicates that a required rule is blocking legitimate traffic.