From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 14:33:19 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE21E37B401 for ; Wed, 2 Jul 2003 14:33:19 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id B83BC43F85 for ; Wed, 2 Jul 2003 14:33:18 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 21859 invoked from network); 2 Jul 2003 21:33:18 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by 0 with SMTP; 2 Jul 2003 21:33:17 -0000 Message-ID: <3F034F99.2080607@tenebras.com> Date: Wed, 02 Jul 2003 14:33:13 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> <20030702185538.GA4555@pit.databus.com> In-Reply-To: <20030702185538.GA4555@pit.databus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2003 21:33:20 -0000 Barney Wolff wrote: > On Wed, Jul 02, 2003 at 11:44:14AM -0700, Michael Sierchio wrote: > >>>NAT is not a security feature, >> >>Many would disagree with that assertion. > > They would be wrong. Find a real security expert and ask. Clearly that would not be you. Both static and dynamic (or "hide") nat have security functions. > Yes, but it's not necessary to keep state for connections from outside in, > only from inside out. If you have an enemy inside, nothing will help you. Actually, you're quite mistaken. There are reasons for maintaining state for VPN and other connections that are unrelated to public services. And it's probably better to exhaust mbufs at the perimeter than the interior...