Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 ( ) at 2012-11-22 14:08 CST
Host appears to be up.
Host appears to be up.
Host appears to be up.
Host appears to be up.
Host appears to be up.
Host appears to be up.
Host appears to be up.
Host appears to be up.
Host appears to be up.
Host 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
PING ( 56(84) bytes of data.

--- 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?

share|improve this question
up vote 2 down vote accepted

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
Host 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) > 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) > 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) > 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) > 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) > 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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.