From owner-freebsd-net@FreeBSD.ORG Sat Oct 21 22:08:35 2006 Return-Path: X-Original-To: net@freebsd.org 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 DF59A16A403 for ; Sat, 21 Oct 2006 22:08:35 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2857243D5F for ; Sat, 21 Oct 2006 22:08:35 +0000 (GMT) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id QAA11801; Sat, 21 Oct 2006 16:08:21 -0600 (MDT) Message-Id: <200610212208.QAA11801@lariat.net> X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 21 Oct 2006 16:08:14 -0600 To: vova@fbsd.ru From: Brett Glass In-Reply-To: <1161424493.1489.10.camel@localhost> References: <200610210648.AAA01737@lariat.net> <1161424493.1489.10.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-avg-checked=avg-ok-516E617 Cc: net@freebsd.org Subject: Re: Avoiding natd overhead X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2006 22:08:36 -0000 At 03:54 AM 10/21/2006, Vladimir Grebenschikov wrote: > 1. use PF for nat - it does aliasing in kernel space True, but it doesn't let me translate the packets and then continue processing within the firewall -- which is necessary if you want to catch unregistered destination addresses BEFORE translation and then unregistered source addresses AFTER translation. > 2. use in-kernel libalias implementation > (I guess man-page for ng_nat(4) will help) Same problem. I don't know how I could send packets through a Netgraph node in the middle of processing by IPFW and then bring them back at the next rule. I suppose that one solution might be, for lack of a better term, a "kernel divert socket," which would pass packets through a kernel module rather than a user process. (This could actually be used to speed up many things for which the current "userland" divert sockets are now used.) It would then be possible to make a "nat.ko" module, and either provide a utility to control it or roll that functionality into ipfw(8). --Brett