Basic Network Troubleshooting

1. Introduction to Network Troubleshooting

Network troubleshooting is the systematic process of identifying,
isolating and resolving problems that prevent computers, applications, devices or
users from communicating correctly over a network.

A good cybersecurity professional does not simply run commands randomly. Instead,
the professional gathers evidence, tests a reasonable hypothesis, records the
results and changes one relevant variable at a time.

2. Common Network Symptoms

Network problems can appear in many forms.

• No Internet connection
• Cannot reach another computer
• Websites do not load
• Some websites work while others fail
• DNS names cannot be resolved
• Network connection is slow
• Frequent disconnections
• High latency
• Packet loss
• Cannot connect to a specific service or port
• Duplicate IP address warnings
• Unable to obtain an IP address automatically
• Applications report connection timeouts

The same symptom can have multiple causes, so troubleshooting should proceed
from evidence rather than assumptions.

3. A Structured Troubleshooting Method

A practical troubleshooting process can follow these stages:

1. Identify the problem.
2. Gather information.
3. Establish what changed.
4. Form a reasonable hypothesis.
5. Test the hypothesis.
6. Apply the appropriate fix.
7. Verify the result.
8. Document the solution.

This approach prevents unnecessary changes and makes troubleshooting easier to
repeat or escalate.

4. Start With the Physical Layer

Before investigating complicated configuration problems, verify the basic physical
connection.

Check:

• Power status
• Ethernet cable connection
• Wi-Fi connection
• Network interface status
• Switch port status
• Router status
• Link/activity indicators
• Access point availability

A disconnected cable cannot be fixed by changing a DNS setting. Troubleshooting
should therefore begin with the simplest relevant checks.

5. Check the Network Interface

The network interface connects a computer or device to the network.

If the interface is disabled or malfunctioning, higher-level network tests may fail.

Windows

ipconfig /all

Linux

ip addr

These commands can provide information about interfaces, IP addresses, subnet
configuration and other network details.

6. Check the IP Address

A device normally requires a valid IP configuration to communicate with other
systems on an IP network.

Check:

• IP address
• Subnet mask or prefix
• Default gateway
• DNS servers
• Address assignment method

An incorrect address or subnet configuration can prevent communication even when
the physical connection is working.

7. DHCP Problems

Many networks use DHCP to automatically assign IP configuration to clients.

If a device cannot obtain a valid DHCP lease, it may not receive the information
required for normal network communication.

Windows

ipconfig /release
ipconfig /renew

After renewing the address, verify the resulting configuration:

ipconfig /all

Linux systems use different network-management tools depending on the distribution
and configuration.

8. Understanding Link-Local Addresses

When IPv4 DHCP configuration is unavailable, some operating systems may assign
an IPv4 link-local address in the 169.254.0.0/16 range.

A link-local address can allow limited local communication but normally indicates
that the expected DHCP configuration was not obtained.

Therefore, seeing an unexpected 169.254.x.x address can be an important
troubleshooting clue.

9. Test the Local TCP/IP Stack

The loopback address can be used to test local IP networking.

ping 127.0.0.1

If the local TCP/IP stack is functioning, the system should normally respond to
the loopback test.

A successful loopback test does not prove that the external network is working.
It only provides evidence about local networking.

10. Test the Default Gateway

The default gateway is normally the router or Layer 3 device used to reach
other networks.

If the gateway address is known, it can be tested with ping when the environment
permits ICMP traffic.

ping 192.168.1.1

Replace the example address with the actual gateway address in the authorized
test environment.

If the local device can reach its gateway but cannot reach external destinations,
the problem may exist farther along the path.

11. Ping

Ping is a common diagnostic tool that uses ICMP echo requests
and responses to test reachability.

For example:

ping 8.8.8.8

A failed ping does not automatically mean that the destination is offline.
Firewalls and network policies may block ICMP traffic.

12. Test by IP Address and by Hostname

Testing both an IP address and a hostname can help separate DNS problems from
general connectivity problems.

For example:

ping 8.8.8.8
ping example.com

If communication by IP works but name-based access fails, DNS configuration or
DNS resolution becomes an important area to investigate.

13. DNS Troubleshooting

DNS converts human-readable domain names into IP addresses and performs other
name-resolution functions.

If websites cannot be opened by name, test DNS directly.

Windows

nslookup example.com

On supported Windows systems, PowerShell also provides:

Resolve-DnsName example.com

Linux

dig example.com

The exact tools installed may vary by operating system.

14. DNS Troubleshooting Questions

When investigating a DNS problem, ask:

• Is the DNS server configured?
• Can the client reach the DNS server?
• Does the DNS server respond to queries?
• Does the domain have the expected records?
• Is there a local DNS cache issue?
• Is the problem affecting one computer or many users?
• Can the service be reached directly by IP?

15. Check the Routing Table

A routing table tells the operating system how to send traffic to different
networks.

Windows

route print

Linux

ip route

A missing or incorrect default route can prevent communication with networks
outside the local subnet.

16. Traceroute and Tracert

Traceroute tools help identify the network path toward a destination.

Windows

tracert example.com

Linux

traceroute example.com

Depending on network configuration, some hops may not respond or may be hidden.
A missing response at one hop does not necessarily prove that the entire path
is broken.

17. Latency

Latency is the time required for data to travel through a network
path and receive a response where measured.

High latency can make applications feel slow even when bandwidth is sufficient.

Possible causes include:

• Long network paths
• Network congestion
• Wireless interference
• Overloaded network devices
• Routing problems
• Service-provider issues

18. Packet Loss

Packet loss occurs when packets fail to reach their intended
destination or response packets do not return.

Packet loss can cause:

• Slow applications
• Voice and video quality problems
• Repeated retransmissions
• Connection instability
• Timeouts

Packet loss should be measured over an appropriate period rather than concluded
from one failed packet.

19. ARP and Neighbor Information

On IPv4 networks, ARP helps systems associate IP addresses with MAC addresses
on the local network.

Windows

arp -a

Linux

ip neigh

Neighbor information can help troubleshoot local-network communication problems.

20. Port and Service Troubleshooting

A device may be reachable while a particular application service remains
unavailable.

For example, a server may respond to ping but have its HTTPS service unavailable.

This is why troubleshooting should test the actual service when appropriate.

Windows PowerShell

Test-NetConnection example.com -Port 443

This can help determine whether TCP connectivity to a specific destination port
is available from the testing system.

21. TCP Connection Problems

If a TCP service cannot be reached, possible causes include:

• Service is not running
• Wrong destination address
• Wrong destination port
• Firewall blocking the connection
• Routing problem
• Server-side access control
• Network outage
• Application configuration error

Testing the actual destination port can therefore provide more useful evidence
than relying only on ping.

22. Firewall Troubleshooting

Firewalls can intentionally block network traffic. When troubleshooting a blocked
service, verify the relevant firewall policy.

Questions include:

• Is the service supposed to be accessible?
• Which port does it use?
• Is the source network authorized?
• Is there a firewall between the client and server?
• Is the host firewall blocking the connection?
• Are firewall logs showing blocked traffic?
• Was a firewall rule recently changed?

23. Check Whether the Application Is Running

Sometimes the network is functioning correctly but the application service itself
is unavailable.

For example, a web server may have:

• Working network connectivity
• A valid IP address
• A reachable gateway
• Successful DNS resolution
• Open firewall rules

Yet the website may still fail because the web server process has stopped.

Troubleshooting must therefore move from network connectivity to the actual
application when the evidence points in that direction.

24. Distinguishing Network and Application Problems

25. Check Recent Changes

A powerful troubleshooting question is:
What changed?

Recent changes may include:

• New firewall rules
• Router configuration changes
• Switch changes
• DNS changes
• New software installation
• Operating system updates
• IP address changes
• New network equipment
• Changed passwords or authentication policies

A problem that began immediately after a documented change may provide a valuable
clue, although correlation alone does not prove causation.

26. Troubleshooting by Scope

Determine how many systems are affected.

One Device

Investigate the device, interface, local configuration, host firewall and
application.

Several Devices

Investigate shared infrastructure such as switches, wireless access points,
DHCP, DNS, routers and firewalls.

Entire Network

Investigate major infrastructure, service providers, upstream connectivity,
routing and central security controls.

27. Basic Troubleshooting Flow

Problem reported
      |
      v
Check physical connection
      |
      v
Check network interface
      |
      v
Check IP configuration
      |
      v
Test local stack
      |
      v
Test gateway
      |
      v
Test remote IP
      |
      v
Test DNS
      |
      v
Test destination port
      |
      v
Check firewall
      |
      v
Check application
      |
      v
Document and verify

28. Security-Aware Troubleshooting

Cybersecurity professionals must consider security while troubleshooting.

For example, an unfamiliar device may appear on a network. Before taking action,
an analyst should determine whether the device is legitimate, identify the
appropriate owner or administrator and follow the organization’s incident-response
process.

Network troubleshooting should not become unauthorized scanning or intrusion.

29. Troubleshooting Security Events

Network symptoms can sometimes be associated with security events.

Examples include:

• Unexpected outbound connections
• Repeated authentication failures
• Unusual DNS requests
• Unexpected changes to network configuration
• Large amounts of unexplained traffic
• Connections to unauthorized services

These observations do not automatically prove that an attack has occurred.
They should be investigated using appropriate evidence and procedures.

30. Network Logs During Troubleshooting

Useful evidence may come from:

• Firewall logs
• DNS logs
• DHCP logs
• Router logs
• Switch logs
• Operating system logs
• Authentication logs
• Application logs
• Monitoring systems

Correlating timestamps across multiple systems can help establish a more complete
picture of an event.

31. Example Troubleshooting Scenario

A user reports that a website cannot be opened.

A structured investigation might proceed as follows:

1. Confirm whether the computer has network connectivity.
2. Check the IP configuration.
3. Test the local TCP/IP stack.
4. Test the default gateway.
5. Test a known external IP address.
6. Test DNS resolution.
7. Test TCP port 443.
8. Check relevant firewall policies.
9. Check whether the web service is operational.
10. Document the evidence and resolution.

Each test narrows the possible causes.

32. Example: DNS Failure

Suppose a user can reach an external IP address but cannot resolve a domain name.

The evidence points toward investigating DNS rather than immediately replacing
the network cable or changing the router.

Possible checks include:

nslookup example.com

or:

dig example.com

The administrator can then examine DNS configuration, resolver availability,
records and network access to the DNS server.

33. Example: Port Failure

Suppose a server responds to ping but a web application cannot be reached on
TCP port 443.

Possible causes include:

• Web service is stopped
• TCP 443 is not listening
• Firewall is blocking TCP 443
• Server-side access control is blocking the source
• Application configuration is incorrect

Testing the port directly can help narrow the investigation.

34. Documenting Troubleshooting

Professional troubleshooting should produce useful documentation.

Record:

• Date and time
• Device or service affected
• Reported symptoms
• Tests performed
• Observed results
• Configuration changes
• Evidence collected
• Final diagnosis
• Resolution
• Follow-up actions

Good documentation allows another technician or security analyst to understand
what happened without repeating every test from the beginning.

35. PHP Troubleshooting Checklist Example

The following PHP example demonstrates how an application could represent a
network troubleshooting checklist. It does not execute network scans or modify
system configuration.

<?php

$checks = array(
	'Physical connection' => true,
	'Network interface active' => true,
	'Valid IP configuration' => true,
	'Default gateway reachable' => true,
	'DNS resolution working' => false,
	'Required service reachable' => false,
);

foreach ( $checks as $check => $status ) {

	echo htmlspecialchars(
		$check,
		ENT_QUOTES,
		'UTF-8'
	);

	echo ': ';

	echo $status
		? 'PASS'
		: 'CHECK';

	echo '<br>';
}

36. Practical Lab — Basic Network Troubleshooting

Perform this exercise only on a computer and network that you own or are
authorized to administer.

Task 1 — Identify the Configuration

Run:

ipconfig /all

or on Linux:

ip addr
ip route

Record:

• IP address
• Subnet/prefix
• Default gateway
• DNS server
• Network interface

Task 2 — Test Local Networking

ping 127.0.0.1

Record whether the test succeeds.

Task 3 — Test the Gateway

Ping the authorized network’s default gateway.

ping YOUR_GATEWAY_IP

Task 4 — Test DNS

nslookup example.com

or:

dig example.com

Task 5 — Test a Service Port

On supported Windows PowerShell environments:

Test-NetConnection example.com -Port 443

Record the result and explain what each test tells you.

37. Troubleshooting Report Exercise

Create a short report containing:

1. Problem statement
2. Initial observations
3. Network configuration
4. Tests performed
5. Test results
6. Possible causes
7. Confirmed cause if established
8. Resolution
9. Recommended follow-up

38. Important Troubleshooting Rules

• Do not guess when evidence can be collected.
• Start with simple checks before complex ones.
• Change one relevant variable at a time when practical.
• Record what you observe.
• Do not disable security controls without authorization.
• Do not scan or test systems without permission.
• Verify that a fix actually solved the problem.
• Document configuration changes.
• Escalate when the problem is outside your authority or expertise.

39. Module 2 Review

This lesson completes Cyber Security Module 2 — Computer Networking.
The module introduced the networking knowledge required for later cybersecurity
topics.

The module covered:

• Network fundamentals
• LAN and WAN
• IP addresses
• MAC addresses
• Ports and protocols
• TCP/IP
• DNS
• DHCP
• Routers and switches
• Firewalls
• Basic network troubleshooting

40. Review Questions

1. What is network troubleshooting?
2. Why should physical connectivity be checked first?
3. What information does ipconfig /all provide?
4. What is the purpose of a default gateway?
5. What does a 169.254.x.x IPv4 address often indicate?
6. What is the purpose of the loopback address?
7. What does ping test?
8. Why can a successful ping fail to prove that a web service is available?
9. What is DNS troubleshooting?
10. What is the purpose of tracert or traceroute?
11. What is packet loss?
12. What is latency?
13. What information can ARP or neighbor tables provide?
14. Why should a specific service port sometimes be tested directly?
15. How can firewall configuration affect troubleshooting?
16. Why is documentation important?
17. What is the difference between a network problem and an application problem?
18. Why must cybersecurity troubleshooting be authorized?

41. Key Takeaways

• Network troubleshooting should follow a structured methodology.
• Begin with the simplest relevant checks and gather evidence.
• Physical, interface, addressing, routing, DNS, firewall and application layers should be considered.
• IP configuration provides important clues about connectivity.
• Ping is useful but does not prove that every service is working.
• DNS tools help separate name-resolution problems from other connectivity problems.
• Routing tools help identify path and gateway issues.
• Port testing helps determine whether a particular service is reachable.
• Firewall policies can allow or block otherwise functional network services.
• Logs from multiple systems can provide stronger evidence than a single test.
• Good troubleshooting includes documentation and verification.
• Cybersecurity professionals must perform testing only within authorized environments.

42. Conclusion

Basic network troubleshooting is an essential cybersecurity skill because security
professionals need to understand whether unusual behavior is caused by normal
network conditions, configuration problems, service failures or potential security
events.

A disciplined troubleshooting process turns symptoms into evidence. By checking
connectivity step by step—from the physical interface through IP configuration,
routing, DNS, ports, firewalls and applications—an analyst can narrow the problem
without making unnecessary changes.

The knowledge from this module provides the networking foundation needed for the
next stages of the Dwallnet Cyber Security curriculum.