Date: Mon, 24 Sep 2007 13:55:44 -0700 From: Christopher Cowart <ccowart@rescomp.berkeley.edu> To: alexzimnitsky@yandex.ru, freebsd-net@freebsd.org Subject: Re: Large-scale 1-1 NAT Message-ID: <20070924205544.GS19429@hal.rescomp.berkeley.edu> In-Reply-To: <9RCt3Xt6F9n7.d4lvWzS3@smtp.yandex.ru> References: <9RCt3Xt6F9n7.d4lvWzS3@smtp.yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--I30T0A8abtL/6dyk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 24, 2007 at 01:26:13PM +0400, alexzimnitsky@yandex.ru wrote: > original: >> 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=20 >> consider is using an RFC1918 pool and NATing the traffic. >>=20 >> 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. >=20 > do your security foulks want connections to be identifiable=20 > outside-in or inside-out? If inside-out then netflow before single=20 > ip nat should do the trick Complaints from the outside world must be traceable to a single individual behind the NAT. This is a significantly easier, especially in automated case handling, when only one person is using a public IP at a 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. >>=20 >> 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. >>=20 >> The real question is: what's the best way to dynamically update the NAT >> table? >=20 > we used pf to binat people (in parallel with ipfw to filter them).=20 > How are you going to nat them (ipf, pf, netgraph)? Updating rules on=20 > the fly was as simple as reloading them (no disruption to existing=20 > pf states). Netgraph nat states behave similarly. The real problem=20 > with pf binat was when we had about a hundred binat rules it almost=20 > halted the traffic through the router. Are you suggesting that a pf solution isn't going to scale well on the order of 1500 clients? We may even get additional public address space to support 4000 or more clients. Will netgraph scale better? >> It doesn't look like there's any way to have a running natd update its >> configuration without restarting. That's obviously disruptive. >=20 > use ipfw+netgraph instead So you recommend ipfw+netgraph? We don't have any experience working with netgraph. I see ng_nat(4), but if anyone could point me to a more thorough howto, I'd greatly appreciate it. >> 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). >=20 > you are right. It is not. > My expirience is it is bad idea to even have more than a couple of=20 > doezns binat rules in sequence (although i tried it with pf, not=20 > with netgraph). >=20 >> 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. >=20 > my ploblem was how to not reserve large number of small address=20 > pools in advance and use a single pool of /22 to number customers=20 > belonging to many different physical segments (even living behind=20 > different routers). >=20 > i used binat first but it scaled badly, so i found a better=20 > solution. I guess you problem is different. What do you mean? We do have 3 discontiguous subnets (/22, /23, /26), and may add one or more /22 or /23 subnets in the future, so we definitely need the ability to pull from various pools. Our NAT box=20 will be attached to a trunked interface and use vlan interfacess to=20 reach the routers for each of the subnets. Thanks for your experiences trying to get binat to scale -- we were definitely considering the pf+ipnat solution. --=20 Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley --I30T0A8abtL/6dyk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBRvgkUCPHEDszU3zYAQJpEA/9EQW1YzBnMLZ3fjpeJJDrj1juOT8bn18Y vQbXNT9v6+st1uspwLZlH4/0AUn+eYQEl0XpwlgNdPE6RArhjeyGmo74szdl67qv KNZyRlJ88haFFgOiQGKsH5dYqEtD8F3gjJo6UGJtdINuFvqR4o0vkVOB97LnSMhq oTuv0yBqSEy/hwNHWqe2eKqy7eLti5LiArRt0x9lIZ8B37XwD3DhEL+jYdGulCzL KV4AiwMvkU+BO5BftHYyMqODZ7QkT6x2r6uO/rb+4EOIoJty7da3oBWmkAHVuwZL OHYdLyvT9uzWBzdoZ+d6JB8Plhppe7fRUWDLa9nyJvG0MQS099QD8rvU8+V4vnwT TzhXEUeIrx7gerWI0dw/8GtI+ow2m/K0sFpnjF38MgJLqoj5rlojuTmAPSVP+nmc wTbN8AzgRnEEpgO5vT6P+0xBeKpFSlq+b7ixd/CANjKxrCpLSC6dUu2JHgzeT9KA 0A9rJ+R9WaZ1cDz4+Fc89DaJypcdH134HTNyFf4m2m77p7YIcGXYBmoHcUrjtjh8 /tQnvaNy2UllVXTkSns3ef+RbxH/ZkFZ4WrlayG2qxuZfZdB9L1IzBoOoKWgendE WFEwqAHwbc+eOLZtwqhuwosxHZEoh0Dv9odSrObF1d40erk8YZl/YdAhv5HVHTPt 3zHOGcvDNtM= =X2hv -----END PGP SIGNATURE----- --I30T0A8abtL/6dyk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070924205544.GS19429>