Date: Thu, 24 Aug 2000 16:20:43 -0700 From: Greg Rumple <grumple@zaphon.llamas.net> To: Damien Tougas <damien@carroll.com> Cc: freebsd-questions@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Ipnat fails under load? Message-ID: <20000824162043.R24089@zaphon.llamas.net> In-Reply-To: <20000809153924.C18771@carroll.net>; from damien@carroll.com on Wed, Aug 09, 2000 at 03:39:24PM -0400 References: <20000809153924.C18771@carroll.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I am experiencing very similar issues. I am running ipnat on FreeBSD 4.1-STABLE as of 8 days ago. I am running a tiny bit more sophisticated set of rules than you, but in reality not much different. I have a class C of machines (about 100 in total) run through the box (collapsed to a single IP). At any one time we have anywhere from 300-1000 connections through the nat, but this box is a P3-700 with 256 megs of ram. This is not an issue, were not experiencing any lag. What instead we are seeing is we just flat out lose connections to some machines until I as well do a full flush/reload. And today even that didn't fix it, I truly had to reboot the box. For example, I had a machine outside the nat, that I connect to regularly. I could not telnet to it, I could not ping it, or anything through the nat. I even tried from the nat directly, and couldn't do any of those items (this machine is in another facility). I could reach other machines 1 ip address above or below it though (which is what's weird). So I even brought up tcpdump on the external interface, and could see the echo requests and echo replies when pinging. Just the kernel wasn't picking them up. This is the third or fourth time I have reached such a state, and this time it could only be fixed via a reboot. Unfortunately I accidently killed the X term that I had all the tcpdump captures, and information in so I don't have that readily available. But I am seeing similar issues. This is a pretty heavy load for a nat, and we realize it, but it's our only option right now. And I really don't wanna use natd, since I would have to deal with ftp proxy/passive issues. * Damien Tougas (damien@carroll.com) [000824 20:44]: > Hello, > > After some period of time (anywhere from days to weeks), ipnat stops > working properly. We ran a tcpdump on the interface while the problem > was occurring, just to see what was going on. What we found was that > any new connections attempted from 10.0.0.0/8 were going through with > the ack bit set only, it is like the initial packet was somehow > blocked. As a result, the server we were trying to contact replied > with a tcp reset since it thought that we were trying to connect to a > session that did not exist. Our first thought was that we might have > ran out of ports, but we have since found that there are typically no > more than about 3000 sessions active when this occurrs. > > The only way to get it to work again is to clear the ipnat tables and > rules and re-initialize them using the following sequence: > > /usr/sbin/ipnat -CF /usr/sbin/ipnat -f /etc/rc.nat > > After that, everything works just fine. The config file we use > (rc.nat) is very simple: > > map de0 10.0.0.0/8 -> 0/32 portmap tcp/udp 1025:65000 > > There are currently no other firewall rules being used. All IP > addresses on the machine are static. The reason we use the 0/32 > designation is to maintain configuration file consistancy across all > servers. > > We are running ipnat on FreeBSD version 3.4-Stable, I am not sure > exactly what version of ipfilter it is, it is the one that comes as > part of the base OS. > > Any ideas? > > Thanks for your help. > > -- Damien Tougas Carroll-Net, Inc. http://www.carroll.com > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe > freebsd-stable" in the body of the message -- Greg Rumple grumple@zaphon.llamas.net 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?20000824162043.R24089>