Re: nmap won't work with policy route

[John Bond <john.r.bond () gmail com>]

i did a bit more digging and it seems that different tools react
differently.
    * nmap sends an arp request with the wrong interface source
    * ping sends an arp request with the correct interface source
    * traceroute/dig to the correct thing (tested on
tcp/udp/icmp(traceroute only)

Im not a coder but my best guess would be perhaps different libc function
calls or different socket options.

regards john

p.s. for reference here is linking info

# ldd `which ping`
linux-vdso.so.1 =>  (0x00007fffa43ff000)
libidn.so.11 => /lib64/libidn.so.11 (0x00007f800b7db000)
libc.so.6 => /lib64/libc.so.6 (0x00007f800b448000)
/lib64/ld-linux-x86-64.so.2 (0x00007f800bc36000)
# ldd `which traceroute`
linux-vdso.so.1 =>  (0x00007fff8d97f000)
libm.so.6 => /lib64/libm.so.6 (0x00007f666c11a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f666bd87000)
/lib64/ld-linux-x86-64.so.2 (0x00007f666c3aa000)
# ldd nmap/nmap
linux-vdso.so.1 =>  (0x00007ffffb9ff000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f8910387000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f8910081000)
libm.so.6 => /lib64/libm.so.6 (0x00007f890fdfc000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f890fbe6000)
libc.so.6 => /lib64/libc.so.6 (0x00007f890f853000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8910597000)



On 6 March 2013 20:36, John Bond <john.r.bond () gmail com> wrote:

> :@ missed a clean up address
>
> default via 193.0.0.97 dev eth1 should have been default via 192.0.2.97
> dev eth1
>
>
> On 6 March 2013 20:34, John Bond <john.r.bond () gmail com> wrote:
>
> > I took a quick look at this on a system where we have a similar routing
> > config.  See below for details.  I tried with nmap 5.5* (what ever is in
> > centos 6.3) and i got the error described in the original email and --route-dst
> > is unavailable.  using the version from nmap i get the following
> >
> > sudo ./nmap -e eth0 --route-dst 8.8.8.8
> >
> > Starting Nmap 6.26SVN ( http://nmap.org ) at 2013-03-06 19:24 UTC
> > 8.8.8.8
> > eth0 eth0 srcaddr 192.0.2.115 nexthop 192.0.2.126
> >
> > sudo ./nmap -e eth1 --route-dst 8.8.8.8
> >
> > Starting Nmap 6.26SVN ( http://nmap.org ) at 2013-03-06 19:24 UTC
> > 8.8.8.8
> > eth1 eth1 srcaddr 192.0.2.102 nexthop 192.0.2.97
> >
> > So everything at this point looks correct; however when i do the actual
> > scan i notice that the wrong source address is selected.
> >
> > sudo ./nmap -e eth0 -sP 8.8.8.8
> > 19:27:24.359034 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> > 8.8.8.8 tell 192.0.2.102, length 28
> >
> > as an FYI using ping picks the correct source
> >
> > ping -I eth0 8.8.8.8
> > 18:53:35.791022 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> > 8.8.8.8 tell 192.0.2.115, length 28
> >
> > Im not sure why its ARPing at this point thats an unrelated issue the
> > point is that the outgoing traffic is sourced with the address of eth1.
> > ill do some further work to fix the server so its not arping and is instead
> > sending this traffic via the Layer 3 gateway.  I thought i would post to
> > say that
> >     - it looks like the correct route is selected with recent versions of
> > nmap
> >     - Its possible that the wrong source addresses is being selected*
> >
> > Regards
> > John
> >
> > *there dose appear to be a layer three issue on this interface however as
> > show ping acts how i would expect it to regardless of this
> >
> >
> > ip route
> > 192.0.2.112/28 dev eth0  proto kernel  scope link  src 192.0.2.115
> > 192.0.2.96/28 dev eth1  proto kernel  scope link  src 192.0.2.102
> >
> > ip route ls table internal
> > default via 193.0.0.97 dev eth1
> > default via 192.0.2.126 dev eth0
> >
> > ip rule
> > 0: from all lookup local
> > 32761: from 192.0.2.102 lookup internal
> > 32762: from 192.0.2.115 lookup external
> > 32764: from all iif lo lookup internal
> > 32765: from all iif lo lookup internal
> > 32766: from all lookup main
> > 32767: from all lookup default
> >
> >
> > On 2 March 2013 01:48, David Fifield <david () bamsoftware com> wrote:
> >
> > > On Fri, Mar 01, 2013 at 09:19:33AM +0800, Taburiss S wrote:
> > > >     I'm trying to write a shell script to test every network interface
> > > in
> > > > one server. I have some policy routing rules like below:
> > > >
> > > > #ip rule
> > > > 0: from all lookup local
> > > > 1:     from <IP of ppp0> look up ppp0_RT   // <-- （ppp0_RT = default
> > > via
> > > > <gateway of ppp0>）
> > > > 2:   from <IP of ppp1> look up ppp1_RT   // <-- （ppp1_RT = default via
> > > > <gateway of ppp1>）
> > > > 32766: from all lookup main
> > > > 32767: from all lookup default
> > > >
> > > > And the main routing table is shown below
> > > > Kernel IP routing table
> > > > Destination     Gateway         Genmask         Flags Metric Ref    Use
> > > > Iface
> > > > 172.16.126.229  *               255.255.255.255 UH    0      0
> > >  0 ppp1
> > > > 172.16.126.240  *               255.255.255.255 UH    0      0
> > >  0 ppp0
> > > > default               *               0.0.0.0                U     0
> > >    0
> > > >        0 ppp0
> > > >
> > > > Since I want to test every ppp interface, I need to use nmap -e to
> > > specify
> > > > an output interface like this:
> > > > # nmap -e ppp0 -sP 8.8.8.8
> > > > This worked well, but
> > > > # nmap -e ppp1 -sP 8.8.8.8
> > > > end up with an error:
> > > > nexthost: failed to determine route to 8.8.8.8
> > > >
> > > > I find that if ppp1 is not 'default' in main routing table, even I
> > > have a
> > > > ip rule whose priority is higher than the main table, I can't use nmap
> > > -e
> > > > to force my ping packet goes out through this ppp1 interface. The only
> > > way
> > > > is to set it to the default dev in main table, but if I do that the
> > > same
> > > > problem will happen to ppp0 which can not be 'default' anymore.
> > > >
> > > > In my opinion nmap should find the IP address of the interface that
> > > given
> > > > by -e , and bind a raw socket to this IP, than send ICMP packet to
> > > 8.8.8.8.
> > > > At this point my ip rules should work well, and the 'default' in main
> > > table
> > > > should do nothing with this packet. Actually, I wrote a small program
> > > like
> > > > that , and it do work well.
> > >
> > > What version of Nmap are you using?
> > >
> > > Newer releases of Nmap use the Netlink interface to ask the kernel for
> > > all routing decisions, so I would expect it to work.
> > >
> > > You can get quick feedback on Nmap's routing decisions with the
> > > --route-dst option:
> > >
> > > nmap -e ppp0 --route-dst 8.8.8.8
> > > nmap -e ppp1 --route-dst 8.8.8.8
> > >
> > > David Fifield
> > > _______________________________________________
> > > Sent through the dev mailing list
> > > http://nmap.org/mailman/listinfo/dev
> > > Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/