Nmap ping scan over a VPN tunnel return all hosts alive?
I'm curious as to why running an nmap -sP (ping scan) on a remote subnet linked via a Cisco site-to-site IPSec tunnel returns "host up" status for every IP in the range.
[root@xt ~]# nmap -sP 192.168.108.*
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2012-11-22 14:08 CST
Host 192.168.108.0 appears to be up.
Host 192.168.108.1 appears to be up.
Host 192.168.108.2 appears to be up.
Host 192.168.108.3 appears to be up.
Host 192.168.108.4 appears to be up.
Host 192.168.108.5 appears to be up.
.
.
.
Host 192.168.108.252 appears to be up.
Host 192.168.108.253 appears to be up.
Host 192.168.108.254 appears to be up.
Host 192.168.108.255 appears to be up.
Nmap finished: 256 IP addresses (256 hosts up) scanned in 14.830 seconds
However, a ping of a known-down IP simply times out or doesn't return anything...
[root@xt ~]# ping 192.168.108.201
PING 192.168.108.201 (192.168.108.201) 56(84) bytes of data.
--- 192.168.108.201 ping statistics ---
144 packets transmitted, 0 received, 100% packet loss, time 143001ms
Is there a more effective way to scan live devices connected in this manner?
Solution 1:
Probably a TCP RST. An excerpt from the nmap manual (v 5.00):
The -sP option sends an ICMP echo request, TCP SYN to port 443, TCP ACK to port 80, and an ICMP timestamp request by default. When executed by an unprivileged user, only SYN packets are sent (using a connect call) to ports 80 and 443 on the target. When a privileged user tries to scan targets on a local ethernet network, ARP requests are used unless --send-ip was specified. The -sP option can be combined with any of the discovery probe types (the -P* options, excluding -PN) for greater flexibility. If any of those probe type and port number options are used, the default probes are overridden. When strict firewalls are in place between the source host running Nmap and the target network, using those advanced techniques is recommended. Otherwise hosts could be missed when the firewall drops probes or their responses.
As shown here:
# nmap -sP 10.99.10.19
Host 10.99.10.19 is up (0.0015s latency).
21:31:13.338418 IP (tos 0x0, ttl 51, id 28548, offset 0, flags [none], proto ICMP (1), length 28)
10.0.0.20 > 10.99.10.19: ICMP echo request, id 57832, seq 0, length 8
21:31:13.338625 IP (tos 0x0, ttl 50, id 7277, offset 0, flags [none], proto TCP (6), length 44)
10.0.0.20.63105 > 10.99.10.19.443: Flags [S], cksum 0xe71d (correct), seq 4106918263, win 3072, options [mss 1460], length 0
21:31:13.338780 IP (tos 0x0, ttl 52, id 11356, offset 0, flags [none], proto TCP (6), length 40)
10.0.0.20.63105 > 10.99.10.19.80: Flags [.], cksum 0x3276 (correct), seq 4106918263, ack 774547350, win 1024, length 0
21:31:13.339771 IP (tos 0x0, ttl 55, id 35529, offset 0, flags [none], proto ICMP (1), length 40)
10.0.0.20 > 10.99.10.19: ICMP time stamp query id 23697 seq 0, length 20
21:31:13.340590 IP (tos 0x0, ttl 255, id 63189, offset 0, flags [none], proto TCP (6), length 40)
10.99.10.19.80 > 10.0.0.20.63105: Flags [R.], cksum 0x3272 (correct), seq 1, ack 0, win 1024, length 0
In my case I have a pair of Cisco ASAs locally and run Linux and strongswan on the remote side. It's likely the remote side since the rtt over the tunnel is roughly 7-9ms in average. I see that the other side sends out arp who-has, but that's as far i get without decrypting the remote ipsec peers packets.