Nmap can scan hosts behind NAT devices, but it often appears to the target as if the scan originates from the NAT device’s public IP address, which can be confusing or lead to blocked scans.
Let’s see Nmap in action, scanning a host that’s behind a NAT device.
First, we’ll set up a simple scenario:
- Your Machine: Has a private IP like
192.168.1.10. - NAT Device (Router): Has a private IP on your LAN (e.g.,
192.168.1.1) and a public IP on the internet (e.g.,203.0.113.5). - Target Host: Has a private IP behind the NAT (e.g.,
192.168.1.100) and is only accessible via the NAT device’s public IP.
We’ll use Nmap from your machine to scan the public IP of the NAT device, aiming to reach the target host.
nmap -p 80,443 203.0.113.5
When Nmap sends a SYN packet to 203.0.113.5 on port 80, the NAT device receives it. If the NAT device has a rule to forward traffic on port 80 to 192.168.1.100, it translates the destination IP from 203.0.113.5 to 192.168.1.100 and forwards the packet. The target host 192.168.1.100 sees the packet coming from the NAT device’s private IP (192.168.1.1).
The response from the target host (192.168.1.100) goes back to the NAT device (192.168.1.1). The NAT device then translates the source IP from 192.168.1.1 back to its public IP (203.0.113.5) and sends it back to your machine.
Your Nmap scan on 203.0.113.5 will show open ports if the target host responds and the NAT device has port forwarding configured.
The core problem Nmap faces behind NAT is that it can’t directly address the internal IP of the target. It must scan the public IP of the NAT device. This means:
- Source IP Masking: The target host sees the scan originating from the NAT device’s internal IP address, not your machine’s IP.
- Port Forwarding Dependency: For the scan to reach the target, the NAT device must have specific port forwarding rules configured. Without these, the NAT device will likely drop the incoming scan packets.
- Firewall Rules: The NAT device itself might have firewall rules that block incoming traffic on the scanned ports, even if port forwarding is set up.
To effectively scan through NAT, you need to:
- Know the Public IP: You must have the public IP address of the NAT device.
- Know the Port Mappings: You need to know which internal ports are mapped to which external ports on the NAT device. Often, the internal port and external port are the same, but not always.
- Scan the Public IP: All Nmap commands target the public IP of the NAT device.
Let’s say you want to scan an internal web server on 192.168.1.100 which is port-forwarded on your router (203.0.113.5) to listen on external port 8080 and internally on port 80.
Your Nmap command would be:
nmap -p 8080 203.0.113.5
Nmap sends a SYN packet to 203.0.113.5:8080. The router receives this, sees it’s destined for port 8080, and forwards it to 192.168.1.100:80. If 192.168.1.100 responds on port 80, the router translates the source IP (192.168.1.1) back to 203.0.113.5 and sends the response to you.
A common misconception is that Nmap itself needs to be "NAT-aware." Nmap is a network scanner; it sends packets and interprets responses. The "NAT awareness" is in how you construct your scan commands and how you understand the responses. You’re scanning the public interface, and the NAT device is doing the heavy lifting of translation.
When scanning through a proxy, the situation is different. Nmap can be configured to use SOCKS or HTTP proxies. This is useful if your network requires all outbound traffic to go through a proxy.
To scan through an HTTP proxy, you’d use the --http-proxy option:
nmap --http-proxy http://proxy.example.com:8080 -p 80,443 scanme.nmap.org
Here, Nmap doesn’t send packets directly to scanme.nmap.org. Instead, it sends an HTTP CONNECT request to proxy.example.com:8080, asking the proxy to establish a connection to scanme.nmap.org:80 (or 443). The proxy then performs the connection and relays the traffic. The target scanme.nmap.org will see the scan originating from the proxy’s IP address.
For SOCKS proxies, you’d use --socks-proxy:
nmap --socks-proxy socks5://socks.example.com:1080 -p 22,80,443 198.51.100.10
The target 198.51.100.10 will see the scan originating from the SOCKS proxy’s IP.
The critical detail often missed when scanning through NAT, especially with aggressive scan types like SYN scans (-sS), is the statefulness of the NAT device. When the NAT device forwards a packet from your machine to the internal target, it creates an entry in its state table. This entry tracks the source IP/port and destination IP/port. When the response comes back from the target, the NAT device uses this state table to translate the internal source IP/port back to the external destination IP/port for your machine. If the NAT device doesn’t see an outgoing packet for a specific connection (e.g., if your Nmap scan is blocked before it even leaves your machine, or if the NAT device’s firewall drops the packet before creating a state entry), it won’t know how to route the return traffic. This is why sometimes a scan appears to hang or time out even when the target is technically reachable.
The next hurdle you’ll likely encounter is dealing with firewalls that perform deep packet inspection or have intrusion detection systems (IDS) that can detect Nmap’s patterns, even when masked by NAT or proxies.