Date: Mon, 24 Sep 2007 09:21:52 -0700 From: Julian Elischer <julian@elischer.org> To: freebsd-net@freebsd.org Subject: Re: Large-scale 1-1 NAT Message-ID: <46F7E420.8050202@elischer.org> In-Reply-To: <20070924072517.GL19429@hal.rescomp.berkeley.edu> References: <20070924072517.GL19429@hal.rescomp.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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, >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46F7E420.8050202>