Nmap Development mailing list archives

nmap unable to find routes in FreeBSD jails


From: David Thiel <lx () redundancy redundancy org>
Date: Mon, 30 Apr 2012 15:39:38 -0700

Hello list,

I'm running a couple of hosts that use multiple FreeBSD jails 
(9.0-RELEASE), but noticed recently that I'm unable to perform any scans 
from within them, because nmap is unable to determine its routes.

I've ensured that security.jail.allow_raw_sockets is set, and I've even 
temporarily exposed /dev/mem and /dev/kmem along with /dev/bpf*, to see 
if that helped things, but to no avail. netstat -rn works just fine, so 
I'm not sure what's preventing nmap from going. Any troubleshooting help 
would be appreciated; I've included some basic info below.

# nmap insecure.org

Starting Nmap 5.61TEST5 ( http://nmap.org ) at 2012-04-30 20:38 UTC
nexthost: failed to determine route to insecure.org (74.207.254.18)
QUITTING!



# nmap -dd -iflist

Starting Nmap 5.61TEST5 ( http://nmap.org ) at 2012-04-30 19:51 UTC
************************INTERFACES************************
DEV    (SHORT)  IP/MASK           TYPE     UP MTU   MAC
usbus0 (usbus0) (null)/0          other    up 0
em0    (em0)    206.125.172.20/32 ethernet up 1500  52:54:00:27:27:81
lo0    (lo0)    (null)/0          loopback up 16384
lo1    (lo1)    (null)/0          loopback up 16384

ROUTES: NONE FOUND(!)
Reason: 


netstat:

Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif 
Expire
default            206.125.172.17     UGS         0   204559    em0
10.212.212.1       link#4             UH          0      281    lo1
10.212.212.2       link#4             UH          0        0    lo1
10.212.212.3       link#4             UH          0        0    lo1
10.212.212.4       link#4             UH          0        0    lo1
10.212.212.5       link#4             UH          0        1    lo1
10.212.212.6       link#4             UH          0        0    lo1
10.212.212.7       link#4             UH          0        0    lo1
10.212.212.8       link#4             UH          0        0    lo1
10.212.212.9       link#4             UH          0        0    lo1
10.212.212.10      link#4             UH          0        0    lo1
10.212.212.254     link#4             UH          0        0    lo1
127.0.0.1          link#3             UH          0      243    lo0
206.125.172.16/28  link#2             U           0        0    em0
206.125.172.18     link#2             UHS         0        0    lo0
206.125.172.19     link#2             UHS         0        0    lo0 =>
206.125.172.19/32  link#2             U           0        0    em0
206.125.172.20     link#2             UHS         0        0    lo0 =>
206.125.172.20/32  link#2             U           0        0    em0
206.125.172.21     link#2             UHS         0        0    lo0 =>
206.125.172.21/32  link#2             U           0        0    em0
206.125.172.22     link#2             UHS         0        0    lo0 =>
206.125.172.22/32  link#2             U           0        0    em0
206.125.172.23     link#2             UHS         0        0    lo0 =>
206.125.172.23/32  link#2             U           0        0    em0
206.125.172.24     link#2             UHS         0        0    lo0 =>
206.125.172.24/32  link#2             U           0        0    em0

(and so forth, there are a lot of IPs)

I've also run a ktrace, but it's not terribly insightful:

http://redundancy.redundancy.org/kdump-nmap.txt

Thanks!
David
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


Current thread: