From owner-freebsd-security Fri Aug 11 5:43:43 2000 Delivered-To: freebsd-security@freebsd.org Received: from 01.dhcp.hck.carroll.com (core1.hck.carroll.com [216.44.16.2]) by hub.freebsd.org (Postfix) with ESMTP id 9BFD237B53F for ; Fri, 11 Aug 2000 05:43:37 -0700 (PDT) (envelope-from damien@01.dhcp.hck.carroll.com) Received: (from damien@localhost) by 01.dhcp.hck.carroll.com (8.9.3/8.9.3) id IAA24626 for freebsd-security@freebsd.org; Fri, 11 Aug 2000 08:44:35 -0400 (EDT) (envelope-from damien) Date: Wed, 9 Aug 2000 15:39:24 -0400 From: Damien Tougas To: freebsd-security@freebsd.org Subject: Strange ipnat behaviour Message-ID: <20000809153924.C18771@carroll.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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