Date: Mon, 24 Sep 2007 00:25:17 -0700 From: Christopher Cowart <ccowart@rescomp.berkeley.edu> To: freebsd-net@freebsd.org Subject: Large-scale 1-1 NAT Message-ID: <20070924072517.GL19429@hal.rescomp.berkeley.edu>
next in thread | raw e-mail | index | archive | help
--ewGIpL7F8xO9lipn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=20 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. 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? 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. Thanks for your help, --=20 Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley --ewGIpL7F8xO9lipn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBRvdmXSPHEDszU3zYAQLf/w/+P+UfJyspWYEFkVbCWCjiy7MnSXsqqZ8F acbJR/qyXAGySLyPaqcsJnL8Y7tHVQ0cwWgx5C8q+DZdOF8HotOUqnBfZt5B1R7H 4Wtl1ZZMyaggxNY43S1yP1UstPg8xeTrD3h8rGCakwAfVEF8iKFPyvCUm9jDyYEj qZpcaDzssfnJJkWO0eaWTDpLd3TnKVsKMAcKexT9HfjQx6w0VzysQEl85zqV5K89 Sp4vqvGPyVbZspTnjjbtKqSqoV+FAQ9R1cmFiJQqoH4K+ks5KnyL6SV8IlWeO7cj NnnFmZhk9fTU/yFs1PofPSUBgT7D/NHT21Hrcu2j3b2RnmC7oKk3EK8NsOotkTgd 0IEhpN4sXSNScRnkyjZj20XFJLvTObC2AfgZgPbHnSO6PSvfeBtJz4PMOroeCApC 5H5jp4uqMSfCiqfNSeKIGNMjtHvgDSCH2bNYJCSbaQYsY3fQSKkIhOb9P2cRmDoK uYlil+TZAEwzfBQRVQbYwQiQBQs55555UCgsQZVfzAXvEw4/rRZt7VYupMoIWv/c f9Up/UJDYDastEJnLZUbUmdn9UfZtjM5weGat+rt6bzzAVjKlgsINUxAc3nODKQp yMbTcRZ8DT/ycaGKMA0fURGnDcUpEJ5H/eO1s9cKXJhP/r+PyzCCDcmamVtY2Ep4 ChWG4ZZoRkc= =QvqE -----END PGP SIGNATURE----- --ewGIpL7F8xO9lipn--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070924072517.GL19429>