From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 16:21:48 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC68916A41A for ; Mon, 24 Sep 2007 16:21:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outN.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id A55B013C43E for ; Mon, 24 Sep 2007 16:21:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 24 Sep 2007 09:21:47 -0700 X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id CDB301264B0 for ; Mon, 24 Sep 2007 09:21:46 -0700 (PDT) Message-ID: <46F7E420.8050202@elischer.org> Date: Mon, 24 Sep 2007 09:21:52 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20070924072517.GL19429@hal.rescomp.berkeley.edu> In-Reply-To: <20070924072517.GL19429@hal.rescomp.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Large-scale 1-1 NAT 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: Mon, 24 Sep 2007 16:21:48 -0000 Christopher Cowart wrote: > Hello, > > We're working on expanding our wireless network. Unfortunately, we're > running out of IP addresses (aren't we all). As much as I'd love to just > tell everyone to use IPv6, that isn't gonna fly. The next plan to > consider is using an RFC1918 pool and NATing the traffic. > > If only it were that simple. The security folks have mandated that > anyone who can talk to the internet at large must be individually > indentifiable. This means having hundreds of users NATing to a single > internet-routable IP isn't happening. Are you sure it doesn't just mean you need to keep logs of who was NAT'd to what at any time? > > I want to try a setup in which we have a big RFC1918 pool of addresses, > say 10.8/16. In their initial state, these hosts might NAT to a single > public IP and perform some transparent proxying to get them to an > authentication page. The firewall on our NAT box would be extremely > restrictive for these clients. > > When a user authenticates, we will allocate a single public IP for the > session. At this time, our code would use ipfw to move the user into a > different lookup table and also update the NAT table. > > The real question is: what's the best way to dynamically update the NAT > table? I don't think we have the ability to do that. it may take some coding on your part. > > It doesn't look like there's any way to have a running natd update its > configuration without restarting. That's obviously disruptive. > > I also doubt it's a good idea to try to launch a single natd process per > authenticated client. We have a /22 and a /23 in our public pools, and > we expect to max that out (1500+ clients). > > Has anyone attempted a setup like this? Do you have any pointers for > designing this to scale well? We are planning on throwing hardware at > it, but that only gets us so far. never heard of such a setup. I suggest you find out if that is the only solution your security people would accept. (As someone doing security stuff for a few years I think that someone is confused somewhere). > > Thanks for your help, >