1

When connected to VPN (I have used OpenVPN and TunnelBear VPN service) nmap stops working. Ping, nc and other network tools work however nmap doesnt.

When not running vpn, I get:

$ sudo nmap 8.8.8.8

    Starting Nmap 5.51 ( http://nmap.org ) at 2011-12-07 15:38 CST
    Nmap scan report for google-public-dns-a.google.com (8.8.8.8)
    Host is up (0.082s latency).
    Not shown: 998 filtered ports
    PORT    STATE  SERVICE
    53/tcp  open   domain
    113/tcp closed auth

When running over vpn, I get the following:

$ sudo nmap 8.8.8.8

    Starting Nmap 5.51 ( http://nmap.org ) at 2011-12-07 15:08 CST
    Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
    Nmap done: 1 IP address (0 hosts up) scanned in 3.07 seconds

It is like nmap loses the traffic. Doing tcpdump captures shows that the traffic is making it back to the box.

Any mac osx, OpenVPN or nmap experts have an idea?

I am using the latest macports nmap...

3
  • Have tried sudo nmap 8.8.8.8 -e tun0 and it fails.
    – wickett
    Dec 7, 2011 at 23:29
  • Have verified that while on vpn, I can ping 8.8.8.8 and telnet 8.8.8.8 53 but nmap still shows the same as above
    – wickett
    Dec 7, 2011 at 23:30
  • Please show us the routing table sudo route -n?
    – quanta
    Dec 8, 2011 at 4:35

2 Answers 2

1

Try adding the nmap -e option to the command line to specify the interface to use. For example, if tun0 is the VPN interface, then do:

% nmap -e tun0  (plus whatever options) target_IPs
  • -e : Use specified interface

  • --iflist to list the interfaces as Nmap sees them.

2
  • Sadly, same output as if not specifying the interface...
    – wickett
    Dec 7, 2011 at 23:28
  • 1
    I just tested my setup, which is: Lion + OpenVPN connecting to Linode cloud VM running CentOS. Doing a connect() scan will work: % sudo nmap -sT -e tun0 -T5 -P0 <target_IP> (i.e. -sT = TCP connect scan vs TCP SYN scan, avoiding raw packets). Checking what is supported... Dec 8, 2011 at 1:47
0

Use other scaning options

The option --packet-trace reveals the first step of the packet, so you can be sure that you are using the interface you chose with -e

With the light from @Tate Hansen try other scan types like -sT -sN -sX, those already elicited some reply from the targets.

The debug output format activated with -d proved useful to activate the debug messages (it can be overwhelming)

The VPN is a security measure that, depending on the implementation, may have some functions set up in the origin (Firewall or VPN gateway) that may block some kind of traffic by default.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .