Destination Host Unreachable? Read the Reply First

Updated: October 2026

A user can't reach the file server, you ping it, and Windows comes back with "Destination host unreachable." The line right before that message tells you where to look, and it's the part people skip. Here's how to read the reply, which device sent it, and the fix order for destination host unreachable that gets you from ping to root cause without guessing.

What "Destination Host Unreachable" Means

Ping sends an ICMP echo request and waits for an echo reply. "Destination host unreachable" means something on the path answered instead, and the answer was "I can't deliver this." In RFC 792, that's ICMP type 3, code 1: host unreachable.

That's different from "Request timed out." A timeout is silence. Nothing came back within the 4-second default wait, so the packet may have reached the target and been dropped, or never left. An unreachable message is a positive statement from a specific device. That device has an IP address, and ping prints it.

Two cousins show up in the same place. "Destination net unreachable" means a router has no route to the whole network. "General failure" or "Transmit failed" means the PC couldn't even send, which usually points at the adapter or a local VPN or security driver.

Read the "Reply From" Address First

Every unreachable line starts with "Reply from" and an address. That address is the device that gave up.

• Reply from your own IP. Your PC gave up. The target is on your subnet (or your PC thinks it is), your PC asked for its hardware address, and nobody answered.
• Reply from your gateway or another router. Your packet left the building. A router further along couldn't hand it to the next hop or to the final host.
• Request timed out, no reply line at all. Nobody said anything. A firewall dropping ICMP is the usual suspect, and the host may be fine.

This r/networking thread asks why the "reply" comes from the PC doing the pinging. The top-voted answer is ARP.

One scripting trap sits here too. Windows counts an unreachable line as a reply, so the summary can read "Lost = 0 (0% loss)" while nothing reached the target. SS64's ping reference warns that a failed ping doesn't always set a non-zero errorlevel, and suggests checking the output for "TTL=" instead. Monitoring scripts that trust the exit code will report a dead host as up.

Reply From Your Own IP: A Local Subnet Problem

Before a PC can send a packet to a neighbour on the same subnet, it needs that neighbour's MAC address. It broadcasts an ARP request ("who has 192.168.1.50?") and waits. No answer means no MAC, no packet, and your own PC reports the host as unreachable.

So the question becomes: why didn't the target answer ARP? Check these in order.

1. Is the target on? Asleep, powered off, or unplugged all look the same from here.
2. Is it on the same VLAN? A switch port moved to the wrong VLAN keeps the IP but loses the neighbours.
3. Are both subnet masks right? A /16 on one side and a /24 on the other makes one device treat the other as local when it isn't.
4. Is Wi-Fi client isolation on? Guest networks block device-to-device traffic by design, so ARP never gets through.

Look at what your PC learned with arp -a, or Get-NetNeighbor -IPAddress 192.168.1.50 in PowerShell. An "Unreachable" or "Incomplete" state confirms the ARP request went unanswered. Then go and look at the target: its link light, its switch port, its IP settings.

Reply From a Router: Routing and Gateway Problems

When the reply comes from the gateway or a router further out, your PC did its job. Now you're finding the hop that couldn't finish.

Run tracert -d 10.20.30.40. The -d skips name lookups, so it runs faster and a DNS problem can't muddy the picture. The last hop that answers is the router closest to the fault. If that router is on the same network as the target, it's the one failing ARP. If it isn't, it's missing a route.

Then check the PC's own routing table with route print or Get-NetRoute. Look for a static route someone added by hand and forgot. Look for a server with two NICs and two default gateways, where replies leave by the wrong interface. And look for a VPN client whose home subnet overlaps the office range, so traffic for 192.168.1.x never enters the tunnel.

For a packet-level view of which device sends the unreachable message and why, this Wireshark walkthrough from The Technology Firm is worth the time.

Firewalls: When Blocked Looks Like Broken

Firewalls usually cause timeouts, not unreachable messages. Windows Defender Firewall on a typical client drops inbound echo requests quietly, so ping times out while file sharing and RDP work fine. From outside the network, a host behind NAT only answers on a port the router sends to it, which is what port forwarding sets up.

Some firewalls reject instead of dropping. They send back an ICMP unreachable with an "administratively prohibited" code, which reads like a network fault when it's a rule. If the reply comes from a firewall's address, read its logs before touching anything else.

Ping only tests ICMP. The user cares about a service, so test that directly: Test-NetConnection fileserver01 -Port 445. If the port answers, the host is reachable and the ping result was a firewall choice. To see what the local Windows firewall is dropping, Microsoft's TCP/IP troubleshooting guide shows how to turn on Filtering Platform drop auditing and match the event to a rule.

When It Comes and Goes: Duplicate IPs and Stale ARP

An unreachable error that clears after a reboot, then comes back days later, is often an ARP problem. Two devices answering for one IP take turns winning. Whichever MAC your PC cached last decides whether ping works.

This r/sysadmin thread describes exactly that pattern on a monitoring server. One reply names the culprit from experience: a new printer someone had given the gateway's IP address.

Check the System log for Tcpip event 4199, which Windows writes when it sees an address conflict and includes the other device's MAC. Clear the local cache with netsh interface ip delete arpcache and ping again. If the MAC in arp -a changes between runs, you've found two devices on one address. Fix the static assignment or add a DHCP reservation, and the flapping stops.

A Fix Order That Doesn't Waste an Hour

Work from the cheapest check to the most disruptive one.

1. Read the "Reply from" address and decide: local, routed, or silent.
2. ipconfig /all on the source. Check the IP, mask and gateway.
3. Ping the default gateway. If that fails, stay on this subnet.
4. arp -a or Get-NetNeighbor for the target, then check the target's port, VLAN and mask.
5. tracert -d to find the last hop that answers, then route print for stray routes.
6. Test-NetConnection -Port for the service the user needs.

The same checks run fine as a script. OpenFrame can run one across a client's devices and collect the output, so you compare twenty ARP tables instead of remoting into twenty PCs.

If ping by IP works and ping by name doesn't, the fault is name resolution, covered in our guide to DNS server not responding. For the PowerShell side of these commands, keep our PowerShell commands cheat sheet open.