From owner-freebsd-questions@FreeBSD.ORG Thu Jul 10 15:23:23 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43A7E37B40A for ; Thu, 10 Jul 2003 15:23:23 -0700 (PDT) Received: from twix.hotpop.com (twix.hotpop.com [204.57.55.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74E9143F93 for ; Thu, 10 Jul 2003 15:23:22 -0700 (PDT) (envelope-from kitbsdlists@HotPOP.com) Received: from hotpop.com (kubrick.hotpop.com [204.57.55.16]) by twix.hotpop.com (Postfix) with SMTP id C507A4632D0 for ; Thu, 10 Jul 2003 22:23:07 +0000 (UTC) Received: from fortytwo. (ip68-109-49-234.lu.dl.cox.net [68.109.49.234]) by smtp-1.hotpop.com (Postfix) with SMTP id D8E141A01CE; Thu, 10 Jul 2003 22:21:48 +0000 (UTC) Date: Fri, 11 Jul 2003 18:20:53 -0500 From: Vulpes Velox To: Matthew Emmerton Message-Id: <20030711182053.022b3292.kitbsdlists@HotPOP.com> In-Reply-To: <20030710165545.L32209-100000@skippyii.compar.com> References: <200307101957.NAA01395@lariat.org> <20030710165545.L32209-100000@skippyii.compar.com> X-Mailer: Sylpheed version 0.8.10claws (GTK+ 1.2.10; i386-portbld-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-HotPOP: ----------------------------------------------- Sent By HotPOP.com FREE Email Get your FREE POP email at www.HotPOP.com ----------------------------------------------- cc: brett@lariat.org cc: questions@freebsd.org Subject: Re: Dead natd -> dead system X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2003 22:23:23 -0000 On Thu, 10 Jul 2003 16:56:12 -0400 (EDT) Matthew Emmerton wrote: > On Thu, 10 Jul 2003, Brett Glass wrote: > > > While working with a FreeBSD system this afternoon, I did something which killed > > natd (the NAT daemon), which was processing packets in the usual way via ipfw > > and a divert socket. > > > > The result? Network communications on the system simply went dead. > > > > It seems to me that ipfw should be able to "self-heal" (that is, bypass the > > rule) or reinvoke a daemon that's attached to a divert socket. Otherwise, > > the process that's attached to the socket becomes an Achilles' heel for > > the whole system. Crash it for any reason, and the system's offline. > > > > Ideas? > > Use kernel-mode IPNAT instead of user-mode natd? What is kernel-mode IPNAT?