The most surprising thing about network troubleshooting is how often the problem isn’t the network at all, but a misconfiguration or resource exhaustion on the endpoints themselves.
Let’s walk through a common scenario: a user reports they can’t reach a critical internal service, say, a Jira instance at 10.10.1.50. Instead of immediately diving into router logs, we start at the source.
First, verify basic connectivity from the user’s machine.
ping 10.10.1.50
If this fails, we escalate to the next layer.
Next, check the user’s local network configuration. Are they even on the right subnet?
ip addr show eth0 # On Linux/macOS
ipconfig /all # On Windows
Look for an IP address in the 10.10.0.0/16 range (assuming that’s the internal network) and a valid default gateway. If the IP is 169.254.x.x, it means they didn’t get an IP from DHCP.
If the IP and gateway look good, check the DNS resolution. Can the user’s machine even find the Jira server by name?
dig jira.internal.company.com @10.10.0.1 # Using internal DNS server
If DNS fails, the problem is likely with the DNS server (10.10.0.1 in this example) or the client’s ability to reach it.
Now, let’s assume DNS is working, and ping to 10.10.1.50 still fails. It’s time to check the local firewall on the user’s machine. Many endpoint security solutions include host-based firewalls that can block traffic.
sudo ufw status # On Ubuntu/Debian
sudo firewall-cmd --list-all # On CentOS/RHEL
# On Windows, check Windows Defender Firewall settings
Ensure that outbound traffic to 10.10.10.50 on the relevant port (likely 80 or 443 for Jira) is permitted.
If the local firewall is clear, we move to the network path. Trace the route from the user’s machine to the destination.
traceroute 10.10.10.50 # On Linux/macOS
tracert 10.10.10.50 # On Windows
This command shows each hop (router) the traffic takes. If it stops at a particular hop, that router is the likely culprit or the point where traffic is being dropped.
If traceroute shows traffic reaching the subnet of the Jira server but not the server itself, check the server’s own firewall. The Jira server might have its own firewall rules blocking incoming connections.
sudo iptables -L # On Linux
# On Windows, check Windows Defender Firewall settings
Verify that the Jira port (e.g., 8080 for Jira) is open for incoming connections from the user’s IP range.
Finally, if all network paths and firewalls appear clear, the issue might be with the Jira service itself. Is the application running and listening on its port?
sudo netstat -tulnp | grep 8080 # On Linux, replace 8080 with Jira's port
# On Windows, use Get-NetTCPConnection in PowerShell
If the port isn’t listed, the Jira application might have crashed or failed to start. Restarting the Jira service would be the next step.
The mental model for network troubleshooting is a layered approach, often visualized as the OSI model or TCP/IP model. You start at the physical layer (though rarely directly troubleshooting cables unless obvious) and move up, verifying each layer’s functionality before proceeding. Physical, Data Link, Network, Transport, Session, Presentation, and Application. Each layer has specific tools and checks. For instance, at the Network layer, we use ping and traceroute to check IP connectivity and routing. At the Transport layer, we use telnet or nc (netcat) to test port accessibility.
One thing that often trips people up is the statefulness of firewalls and NAT. A firewall might allow traffic to a server, but if the return traffic from the server isn’t allowed back through the same firewall (or a corresponding NAT rule isn’t in place), the connection will appear to hang. This is especially common with complex security policies or when dealing with asymmetrical routing where return traffic takes a different path.
After fixing the Jira connectivity, the next problem you’ll likely encounter is slow loading times for the Jira dashboard, indicating a potential performance bottleneck on the Jira server or its database.