In a complex network environment, the problem of "reachable route but inaccessible IP" is like an invisible wall, leaving operation and maintenance personnel in a fog. When the ping command indicates that the network layer is normal and the traceroute path is intact, the packet cannot reach the destination port. This phenomenon often exposes deep-seated problems at the transport layer and above. Let us deeply analyze the ten technical causes of such failures, and provide systematic diagnosis methods and solutions.

1.Firewall interception: the invisible gatekeeper of network traffic

The firewall is the primary suspect of IP unreachable. Even if the routing table is correct, communication will fail if a specific protocol or port is blocked by firewall rules. For example, when a Linux server uses iptables, the default policy may discard all inbound traffic:

# View the current firewall rules
iptables L n v
# Open port 80
iptables A INPUT p tcp dport 80 j ACCEPT

Windows systems need to check the Windows Defender firewall to ensure that the corresponding program or port is allowed in the inbound rules. The security group configuration of cloud servers (such as AWS and Alibaba Cloud) is also critical, and the inbound rules must contain the source IP address and destination port. The security group of an e-commerce platform did not open Redis port 6379, resulting in a database connection timeout, and the fault lasted for 6 hours.

2. NAT translation failure: The mapping maze of Intranet and extranet addresses

On an enterprise network, the NAT device is responsible for IP address translation. If the route is normal but NAT entries are missing or incorrectly configured, the public IP address cannot be mapped to the Intranet host. Example of checking router NAT configuration:

cisco
interface GigabitEthernet0/1
ip nat inside
interface GigabitEternet0/0
ip nat outside
ip nat inside source static 192.168.1.100 203.0.113.5

If the internal server IP address 192.168.1.100 is not correctly bound to the public IP address 203.0.113.5, external access 203.0.113.5 will not respond. The existence of the nat entry can be verified using show ip nat translations.

3.ACL access control: fine filter of traffic

The access control lists (ACLs) of network devices (routers and switches) may quietly block traffic. The core switches of a financial company are configured with the following ACLs:

cisco
accesslist 101 deny tcp any host 10.1.1.10 eq 22. Accesslist 101 deny TCP any host 10.1.1.10 eq 22
accesslist 101 permit ip any any

This rule forbids all SSH access to 10.1.1.10. As a result, O&M personnel cannot remotely log in. Run the show accesslists command to check the number of matched rules. If the number of deny rules keeps increasing, adjust the ACL policy.

4.MTU mismatch: the silent killer of packet fragmentation

When the MTU (maximum transmission unit) of a network segment in a path is smaller than the packet size, fragmentation fails and transmission is interrupted. Use the following command to detect MTU problems:

# Set the do not fragment flag and gradually increase the package size
ping M do s 1472 10.1.1.1 # 1472+28=1500

If 1472 bytes can be connected while 1473 bytes cannot be connected, MTU mismatch exists. Solutions include adjusting the interface MTU or enabling TCP MSS clamping:

cisco
interface GigabitEthernet0/1
ip tcp adjustmss 1360

5.service monitoring status: the last barrier of the application layer

Even if the network layer is unblocked, if the target service is not listening on the specified port, the connection is still denied. Fast verification using netstat or ss:

# Check the listening status of port 80
netstat tuln | grep ':80'
ss ltn 'sport = :80'

If the output is empty, the Web service (such as Nginx) needs to be started. The Docker container needs to check that the port mapping is correct:

docker
docker run d p 8080:80 nginx # Maps container 80 port to host 8080

6.DNS resolution trap: domain name to IP conversion fog

Incorrect DNS resolution results in incorrect access to the destination IP address. Use nslookup or dig to check:

dig example.com @8.8.8.8
nslookup example.com

Check whether the local hosts file (/etc/hosts or C:\Windows\System32\drivers\etc\hosts) contains an error entry. An enterprise Intranet fault occurs because the test IP address is incorrectly set to the production IP address in the hosts file, resulting in service system confusion.

7. Protocol restrictions: Status difference between ICMP and TCP

Network devices may allow ICMP (ping) but block TCP/UDP. Verify port accessibility using Telnet or Nmap:

telnet 10.1.1.1 80
nmap p 443 10.1.1.1

If ICMP passes but TCP fails, check the protocol filtering rules of the intermediate device. A cloud platform permits ICMP by default but disables all TCP ports. You need to manually enable the service ports.

8.Dual stack network conflict: the priority game between IPv4 and IPv6

When both IPv4 and IPv6 are enabled on the host, the application may incorrectly use the IPv6 address. ping 4 and ping 6 to force the protocol version:

ping 4 example.com # Enforce IPv4
ping 6 example.com # Enforce IPv6
You can adjust the IPv6 priority by modifying /etc/gai.conf:
config
precedence ::ffff:0:0/96 100 # Precedence IPv4

9.QoS policy error: Side effects of bandwidth management

Quality of Service (QoS) policies may incorrectly speed up or drop specific traffic. Check router configuration:

cisco
classmap matchany VIDEO
match protocol rtp
policymap LIMIT_VIDEO
class VIDEO
police 1000000 8000 exceedaction drop

The preceding policy limits RTP traffic to 1Mbps and discards it if the RTP traffic exceeds the limit. Run the show policymap interface command to check whether policies are matched.

10. security equipment misjudgment: IPS/WAF excessive protection

An intrusion prevention system (IPS) or Web application firewall (WAF) may misjudge legitimate traffic as an attack. Check intercept records in the log:

log
[WAF Alert] SQL Injection detected from 192.168.1.100

Temporarily disable rules or add whitelisting for quick verification:

nginx
ModSecurityRuleEngine Off
SecRuleRemoveById 942100

11.Systematic diagnostic process

Client verification Check the local firewall and hosts file, and use telnet/nc to test port connectivity. Also perform network path analysis traceroute Tp80 Trace TCP paths and capture packet analysis (Wireshark/tcpdump). Then check the server side, confirm the service process listening status and review the application log (journalctl u nginx). When checking intermediate devices, you need to log in to the switch to check the ACL count and verify the sticky session of the load balancer.

When routes are reachable but IP is inaccessible, everything from firewall rules to service status, NAT mapping to protocol compatibility can be a point of failure. Only by using a systematic diagnosis method, using tools such as tcpdump and Wireshark to analyze traffic, and combining log review and configuration verification, can you clear the fog and get to the core of the problem.