32_1: Overview:

This lab will explore a scenario where an application team is unable to ping or telnet to an application server. While the issue may seem like a network problem, we will investigate step by step to determine the actual cause and demonstrate that there is no network issue. The lab will cover essential troubleshooting methods and configurations in detail

32_2: Scenario

We have two application servers configured as follows:

Server on Port 22:

Telnet to this server is functioning correctly, confirming that the service on port 22 is accessible.

Server on Port 3022:

Telnet to this server results in the following error:

telnet: connect to address 10.0.0.35: No route to host

This suggests that there is a configuration or access issue specific to port 3022.

In the following sections, we will methodically investigate the root cause of the issue and validate that it is unrelated to network connectivity. Step-by-step troubleshooting will highlight any service, firewall, or routing configurations contributing to the error.

32_3: Checking Firewall config

• Ingress Rule

• After allowing the ports in Ingress Rules, ping (ICMP) and telnet (for ports 22 & 3022)

  Ping is working.

Telnet on port 22 is working but not on 3022.

32_4: Observations and Current Findings

Thus far, the following validations have been completed:

• Instance Status: The server/instance is confirmed to be running.

• Network Configuration: Ingress and egress rules in the security list have been validated and updated to include both port 22 and port 3022.

• Connectivity to Port 22: Telnet to port 22 is successful, confirming connectivity and proper configuration for this port.

• Connectivity to Port 3022: Despite adding port 3022 to the ingress rules, Telnet to this port still fails with a "No route to host" error.

At this stage, while the network configuration appears to be correct, it is unclear whether the application on port 3022 is running and listening. The next step will involve verifying the application’s status to determine whether it is bound to port 3022 and accepting connections.

32_5: Conclusion

netstat -plan| grep -i 22

The absence of output for port 3022 in the netstat command indicates that no application or service is actively listening on that port. This finding suggests that the issue is not with the network configuration but rather with the application setup on the server.

Explanation:

• Port 22 Output: The netstat command for port 22 shows that the SSH daemon (sshd) is listening and accepting connections. This confirms the functionality of services on port 22.

• Port 3022 Output: Repeated attempts to query port 3022 (netstat -plan | grep -i 3022) produce no results. This strongly implies:

• The application expected to listen on port 3022 is not running.

• The application might not be configured correctly to bind to port 3022.

• There may be a misconfiguration in the service startup script or application settings.

32_6: Understanding netstat -plan command

• A network utility that provides detailed information about active network connections, including:
  • Listening ports
  • Established connections
  • Network protocols in use
  • Process IDs (PIDs) and application names associated with connections

-p: Show Process Information Displays the PID (Process ID) and the name of the application or service managing the connection. Example: 2209/sshd indicates the SSH daemon (sshd) is responsible for this connection.

-l: Show Listening Ports Restricts the output to only show ports in the LISTEN state, i.e., ports actively waiting for incoming connections. Example: The line 0.0.0.0:22 shows that port 22 is listening for incoming SSH connections.

-a: Show All Connections Includes both listening ports and established connections in the output.

-n: Show Numerical Addresses Displays raw IP addresses and port numbers instead of resolving them to hostnames or service names. Example: 0.0.0.0:22 is displayed instead of *:ssh.