From owner-freebsd-security Fri Aug 11 8:46: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from databits.net (analog.databits.net [207.29.192.55]) by hub.freebsd.org (Postfix) with SMTP id 1AD4637BF7C for ; Fri, 11 Aug 2000 08:46:00 -0700 (PDT) (envelope-from petef@databits.net) Received: (qmail 24309 invoked by uid 1000); 11 Aug 2000 15:45:54 -0000 Date: Fri, 11 Aug 2000 11:45:53 -0400 From: Pete Fritchman To: Damien Tougas Cc: freebsd-security@freebsd.org Subject: Re: Strange ipnat behaviour Message-ID: <20000811114553.A20991@databits.net> References: <20000809153924.C18771@carroll.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000809153924.C18771@carroll.net>; from damien@carroll.com on Wed, Aug 09, 2000 at 03:39:24PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Since you are pointing the map to a dynamic IP (probably), 0/32, you will have to run "ipf -y" to refresh the rules whenever your dynamic IP changes. Regards, Pete ++ 09/08/00 15:39 -0400 - Damien Tougas: >Hello, > >We are currently 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. > >The problem that we are seeing is that for some reason unknown to us, >nat just stops working. 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 >map de0 10.0.0.0/8 -> 0/32 > >Could that second line be causing the problem? >There are currently no ipf rules being used. > >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 is >non existent. Our first thought was that we might have ran out of >ports, but we discovered that there were no more than about 3000 >sessions active at the time. > >Any ideas? Is this a bug, or have we mis-configured something? > >Thanks for your help. > >-- >Damien Tougas >Carroll-Net, Inc. >http://www.carroll.com > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message -- Pete Fritchman Databits Network Services, Inc http://www.databits.net finger: petef@analog.databits.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message