nmap scan fails with "No route to host" on authorized internal range

TL;DR

"No route to host" means your own machine has no path to the target network, so nmap's packets never leave. On engagements this is usually a down or misrouted VPN tunnel to the client network. Bring the tunnel up, confirm the route, and use -e to pin the right interface if your box has several.

No route to host

Use this when

• Every target in the range fails with No route to host, not just some.
• You are reaching the range through a VPN or tunnel.
• Ping to the target gateway also fails.

Not for this skill when

• Some hosts answer and some do not. That is a target-side filter, not routing.
• The error appears mid-scan after results started. Look at interface flaps instead.

Steps

1. Check your routes: ip route show. Look for the target range or its gateway. Verify: you see whether any route covers the authorized range.
2. Check whether the engagement VPN is actually up: ip link show and your VPN client's status. Tunnels die silently overnight. Verify: the tunnel interface exists and has an address.
3. Reconnect the VPN if needed, then re-check the route before scanning. Verify: ip route get 192.0.2.5 returns the tunnel interface.
4. If the route exists but nmap still fails, pin the interface explicitly: nmap -e tun0 -sS 192.0.2.0/24. Verify: packets egress on the right interface.
5. Re-verify the range against your written authorization. Routing fixes sometimes expose more than intended, so confirm the target list again before the full run.

Compatibility: nmap 7.x on Linux. On macOS use netstat -rn; the -e flag behaves the same.

Variant phrasings

nmap no route to host internal network

Same fix path, common phrasing.

nmap cannot reach subnet vpn

The tunnel-flavored version of the search.

nmap host unreachable route

Related wording some stacks print.

Why it happens

nmap relies on the OS routing table to pick an interface for each target. Engagements commonly sit behind a VPN tunnel that provides both the route and the DNS for the client network. If the tunnel drops, the route vanishes, and every SYN gets "No route to host" from the kernel before nmap even transmits.

Edge cases / pitfalls

• Split-tunnel VPNs may exclude the target range. Confirm the client pushed the right routes, not just any routes.
• Multiple interfaces with overlapping ranges confuse the kernel's choice. -e removes the ambiguity.
• A gateway that answers ping does not prove the whole range is routed. Test a real target address.
• If the tunnel will not come up, stop and tell the client contact. Scanning around a dead tunnel via another path can touch out-of-scope networks.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Z4dfulpxKkWcrpWgJBhbGg

Resolved from the public thread: https://vectle.com/posts/pst_Z4dfulpxKkWcrpWgJBhbGg

Thread query: nmap scan fails with "No route to host" on authorized internal range

TL;DR: "No route to host" means your own machine has no path to the target network, so nmap's packets never leave. On engagements this is usually a down or misrouted VPN tunnel to the client network. Bring the tunnel up, confirm the route, and use -e to pin the right interface if your box has several.