From owner-freebsd-net@FreeBSD.ORG Mon Oct 23 05:50:52 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 9802B16A417 for ; Mon, 23 Oct 2006 05:50:52 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB09843D4C for ; Mon, 23 Oct 2006 05:50:48 +0000 (GMT) (envelope-from vova@sw.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gbc46-0000XM-5R; Sun, 22 Oct 2006 16:04:30 +0400 From: Vladimir Grebenschikov To: Brett Glass In-Reply-To: <200610212208.QAA11801@lariat.net> References: <200610210648.AAA01737@lariat.net> <1161424493.1489.10.camel@localhost> <200610212208.QAA11801@lariat.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Sun, 22 Oct 2006 16:04:02 +0400 Message-Id: <1161518642.1455.15.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: net@freebsd.org Subject: Re: Avoiding natd overhead X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 05:50:52 -0000 =F7 =D3=C2, 21/10/2006 =D7 16:08 -0600, Brett Glass =D0=C9=DB=C5=D4: > At 03:54 AM 10/21/2006, Vladimir Grebenschikov wrote: > =20 > > 1. use PF for nat - it does aliasing in kernel space >=20 > 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. >=20 > > 2. use in-kernel libalias implementation=20 > > (I guess man-page for ng_nat(4) will help) >=20 > 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. Some years ago, I've managed to use ksocket interface to catch divert packets from ipfw and even return them back (surprisingly it did support divert AF). But, be careful, it is easy to get infinite loop in kernel with this technique. Probably some loop prevention appears in from these times, but I am not sure. > 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). >=20 > --Brett=20 >=20 --=20 Vladimir B. Grebenschikov vova@fbsd.ru