Date: Tue, 22 Jan 2002 15:14:47 -0800 (PST) From: Tom <tom@uniserve.com> To: "Robert D. Hughes" <rob@robhughes.com> Cc: freebsd-stable@freebsd.org Subject: RE: NATD, or another one I haven't seen before Message-ID: <Pine.BSF.4.10.10201221506250.61403-100000@athena.uniserve.ca> In-Reply-To: <B95B566BD245174196CA4EE29E5818831B6452@HEXCH01.robhughes.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Not necessarily. Usually in a NAT situation, traffic must be initiated from the inside, creating a dynamic translation rule. A CodeRed scan will test port 80 on every external IP. Usually in NAT, there is only one external IP. So, I don't this problem has anything to do with NAT, unless NAT is being used to map a block of external IPs to internal IPs. If you have lots of external IPs that you aren't using, CodeRed will cause a lot of ARP (unsucessful) traffic. Packets will have to queued until ARP times out. Lots of unused IPs is a denial of service vunerability. Port scanning them will generate a lot of ARP activity, and force your gateway to buffer a lot of traffic. Unused networks should be removed off of router interfaces, and replaced with Null (blackhole) routes Tom On Tue, 22 Jan 2002, Robert D. Hughes wrote: > If that's the case, then it seems to point to a problem in the way NATD > handles arps. I've hammered this box, as well as others, and never seen > this problem. At any rate, hopefully one of the more senior people can > decide whether a PR is warranted. If so, I'll be happy to submit it. > > Thanks, > Rob > > -----Original Message----- > From: Barry Irwin [mailto:bvi@itouchlabs.com] > Sent: Tuesday, January 22, 2002 1:13 AM > To: Robert D. Hughes > Cc: freebsd-stable@freebsd.org > Subject: Re: NATD, or another one I haven't seen before > > > I dont think this is neccesarily a new source code related bug. During > the > CodeRed / CodeRedII sagas of last year I had a number of NATD's lock up > On a range of boxes from 4.3 right to 4.0, they exhibited a massive > growth > in memory usage 30MB+ and CPU time. Packets were getting handled, but > ere > taking forever, I was getting ping times on the order of 400 seconds. > > This also occured on network segments in 4 different continents. Again > a > pile of arp traffic was seen on the external side of the firewalls. My > initial response was that state table swere filling up because of all > the > incomplete connections, but tests with synfloods by muself were unable > to > duplicate the problem. > > Barry > > > -- > Barry Irwin bvi@itouchlabs.com > +27214875150 > Systems Administrator: Networks And Security > Itouch Labs http://www.itouchlabs.com South > Africa > > On Mon 2002-01-21 (11:48), Robert D. Hughes wrote: > > > > CVSUP from 1/16, running natd with command /sbin/natd -config > /etc/natd.conf -n dc0. Config file is: > > > > log_denied > > log_facility security > > use_sockets > > same_ports > > unregistered_only > > redirect_port tcp x.x.x.x:80 x.x.x.x:80 > > redirect_port tcp x.x.x.x:443 x.x.x.x:443 > > redirect_port tcp x.x.x.x:8880 x.x.x.x:8880 > > redirect_port tcp x.x.x.x:2953 x.x.x.x:2953 > > redirect_port tcp x.x.x.x:2954 x.x.x.x:2954 > > dynamic > > punch_fw 10000:1000 > > > > I'm going to try removing the log options and see if it improves. but > since this is a new issue with the recent cvs build, I did want to send > out a query. > > > > What I'm seeing is natd going to well over 90% cpu on this box, which > has never happened before to the best of my knowledge. What tcpdump is > showing my is very large amounts of arp traffic on the external > interface from a large part of the 12.237/16 network (yeah, I know, lame > provider). Has anyone else been running into similar issues? > > > > "Great spirits have always encountered violent opposition from > mediocre minds." -- Albert Einstein > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-stable" in the body of the message > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10201221506250.61403-100000>