Buffer overflows and NAT and NMAP stops working

kerogaz

kerogaz

Code: 
nmap -Pn 10.44.1.1-250
WARNING: eth_send of ARP packet returned -1 rather than expected 42 (errno=no buffer space available)
What can I do?
 
Are you doing this as root? Firewall blocking outgoing traffic?
 
SirDice said:
Are you doing this as root? Firewall blocking outgoing traffic?
Click to expand...
And so and so. This happens a couple of times a week and then disappears by itself.
As soon as nmap starts sending such messages, the clients of local network lose access the Internet via nat
 
Yes, you seem to be flooding your NAT state tables with NMap requests. This begs the question though, why are you NAT'ing traffic destined for RFC-1918 addresses?

ARP requests are broadcasts, they're not supposed to be routed and should stay inside the broadcast domain. So NAT shouldn't even be involved here.
 
SirDice said:
Yes, you seem to be flooding your NAT state tables with NMap requests. This begs the question though, why are you NAT'ing traffic destined for RFC-1918 addresses?

ARP requests are broadcasts, they're not supposed to be routed and should stay inside the broadcast domain. So NAT shouldn't even be involved here.
Click to expand...
 
No, at first the clients call that there is no access to the Internet via nat, and then I already check them with nmap and receive such messages And as many lines as there are clients on the network
And very big time of ping:
64 bytes from 10.44.5.4: icmp_seq=360 ttl=64 time=7094.897 ms
64 bytes from 10.44.5.4: icmp_seq=362 ttl=64 time=10974.783 ms
64 bytes from 10.44.5.4: icmp_seq=366 ttl=64 time=7510.872 ms
64 bytes from 10.44.5.4: icmp_seq=368 ttl=64 time=5524.071 ms
64 bytes from 10.44.5.4: icmp_seq=369 ttl=64 time=4462.035 ms
64 bytes from 10.44.5.4: icmp_seq=370 ttl=64 time=3441.057 ms
64 bytes from 10.44.5.4: icmp_seq=371 ttl=64 time=2377.596 ms
64 bytes from 10.44.5.4: icmp_seq=372 ttl=64 time=1364.064 ms
64 bytes from 10.44.5.4: icmp_seq=373 ttl=64 time=336.588 ms
Normal is:
64 bytes from 10.44.5.4: icmp_seq=899 ttl=64 time=0.216 ms
64 bytes from 10.44.5.4: icmp_seq=900 ttl=64 time=0.191 ms
64 bytes from 10.44.5.4: icmp_seq=901 ttl=64 time=0.211 ms
64 bytes from 10.44.5.4: icmp_seq=902 ttl=64 time=0.183 ms
64 bytes from 10.44.5.4: icmp_seq=903 ttl=64 time=0.193 ms
64 bytes from 10.44.5.4: icmp_seq=904 ttl=64 time=0.221 ms
^C
 
Why are you flooding your network with more packets if they already have network issues? Do you even know what nmap(1) is and how it works?
 
kerogaz said:
And very big time of ping:
Click to expand...
I get these too, if my ISP has network issues. Slow internet often causes users to constantly F5 (refresh) webpages, causing even more traffic, which slow things down even more (and eventually overflow the NAT state tables).

Instead of just blindly running an nmap(1) scan over your network, do some actual investigating. Look at the amount of traffic for example. Look at the load of your switches for example. Login on the machine that's connecting you to the internet and see if the internet connection itself is slow. The issue may not be on your network but on your ISP's network.
 
Okay, let's leave nmap. Initially, nat does not work correctly. I looked at the ping in LAN - probably because of this, and maybe a loop or a ddos attack LAN
 
Start by providing a rough diagram of your network. I have no idea what your network looks like and how things are configured. I can only guess where the problem might be.
 
Some passive monitoring tool, yaf, ntop, etc. might give you a lot of enlightenment - but while they compactly capture data - they may not be the most trivial to understand after you collect the data.

Capturing PCAPs will definitely have all the information at a very high storage cost. You can do things like create rolling PCAPs that get truncated off over time and link that to flow records captured by something like yaf. (There's some information on that at http://tools.netsa.cert.org - full disclosure, I'm part of CERT.) But that's a bunch of work to setup and operate. Might not be worth the investment for you.

But I would agree that nmap is definitely the wrong tool here. And a network diagram would be really helpful if you want help.
 
Chris Inacio said:
Some passive monitoring tool, yaf, ntop, etc. might give you a lot of enlightenment - but while they compactly capture data - they may not be the most trivial to understand after you collect the data.

Capturing PCAPs will definitely have all the information at a very high storage cost. You can do things like create rolling PCAPs that get truncated off over time and link that to flow records captured by something like yaf. (There's some information on that at http://tools.netsa.cert.org - full disclosure, I'm part of CERT.) But that's a bunch of work to setup and operate. Might not be worth the investment for you.

But I would agree that nmap is definitely the wrong tool here. And a network diagram would be really helpful if you want help.
Click to expand...
Thanks.I use tshark
 
It is not clear to me what kind of buffer this is, for example, to change its size.The problem I understand is multisystem
 
kerogaz said:
It is not clear to me what kind of buffer this is, for example, to change its size.The problem I understand is multisystem
Click to expand...

It is not clear to me (also) what box you're seeing this from? What is upstream? is this the box doing the NAT? Is it the router? What firewall /NAT software? That is, some network description.

It needn't be fancy graphics, text will do fine, but we're blind to what you can see.

If firewall/NAT is ipfw maybe I can help. If pf, others can.
 
kerogaz said:
Code: 
nmap -Pn 10.44.1.1-250
WARNING: eth_send of ARP packet returned -1 rather than expected 42 (errno=no buffer space available)
What can I do?
Click to expand...
The -Pn switch to nmap(1) "Treat(s) all hosts as online -- skip(s) host discovery". So the machine running this command will just blindly try to scan every one of the 250 IP addresses you've specified, regardless of whether there's a host at that address or not. Let me guess, you're also running this in a tight loop? No wonder whatever poor machine you're running this on is running out of ARP buffer space. You're making thousands of useless ARP broadcasts.
 
Jose said:
The -Pn switch to nmap(1) "Treat(s) all hosts as online -- skip(s) host discovery". So the machine running this command will just blindly try to scan every one of the 250 IP addresses you've specified, regardless of whether there's a host at that address or not. Let me guess, you're also running this in a tight loop? No wonder whatever poor machine you're running this on is running out of ARP buffer space. You're making thousands of useless ARP broadcasts.
Click to expand...
No, nmap -sT 10.44.1.1-255 gave the same result and then, I did not ask to scan an infinite number of hosts, but only 255.Not enough buffer for 255 hosts this can't be
 
You must log in or register to reply here.
Back
Top