Date: Mon, 24 Sep 2007 17:06:02 -0700 From: Christopher Cowart <ccowart@rescomp.berkeley.edu> To: freebsd-net@freebsd.org Subject: Re: Large-scale 1-1 NAT Message-ID: <20070925000602.GT19429@hal.rescomp.berkeley.edu> In-Reply-To: <46F82FCF.2090203@net.utcluj.ro> References: <20070924072517.GL19429@hal.rescomp.berkeley.edu> <46F77C27.9050400@net.utcluj.ro> <20070924203516.GQ19429@hal.rescomp.berkeley.edu> <46F82FCF.2090203@net.utcluj.ro>
next in thread | previous in thread | raw e-mail | index | archive | help
--RNYIsZSUNfbU4BwD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 25, 2007 at 12:44:47AM +0300, Cristian KLEIN wrote: >Christopher Cowart wrote: >> On Mon, Sep 24, 2007 at 11:58:15AM +0300, Cristian KLEIN wrote: >>> Christopher Cowart wrote: >>>> 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 ju= st >>>> 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. >>> We used to have this problem too, for some NATed networks. The=20 >>> solution which has been adopted is to capture the flows on the=20 >>> gateway and send them the security team. The netflow protocol is=20 >>> very well suited for this. >>=20 >> We have automated intake and processing for security cases. These often >> just contain the IP the bad traffic appeared to be coming from. While we >> could probably reconstruct things using netflow, we definitely wouldn't >> have the staff time to do so. As such, we'd have to keep this >> information in a database, which will add up fast. Keeping track who was >> using an IP at a given time is relatively easy. Granted, this places the >> complexity in the network and not the security processing, but that's >> where we have resources. > > I must admit I haven't thought of this. With this new information I=20 > am missing a point. Since you need to make a 1-to-1 association=20 > between clients and public IPs, why do you need the NAT at all. Is=20 > this to save public IPs by NOT giving them to unauthenticated users? This is exactly the point. At any given time, people may have their laptop sitting in their rooms plugged into a wired connection or they may be walking near an access point with an iPhone on their person. All of these devices are associating with our APs and eating up public IP addresses, even though they aren't using the network. Our goal is to only allocate the device a public AP after authentication has occured. > There is another thing I wanted to point out. I remember you used the=20 > words "authentication web page". This made me think you are=20 > establishing a captive portal, which is not secure at all. If I=20 > understand well the authpf solution would be secure, except perhaps=20 > a small delay. You might proxy your clients to a "click here and=20 > download this preconfigured PuTTY" page. We are planning on using a captive portal. The only authentication mechanism we have for clients is a web-based SSO solution using CAS that isn't maintained by our staff. The people trying to authenticate are not intended to be local users on the system. What are the security problems you see with a captive portal interface? >>>> The real question is: what's the best way to dynamically update the NAT >>>> table? >>> You may use IPFW with IPNAT or PF instead. PF is able to reload its >>> configuration without disruption. Moreover, because the state table is = not >>> flushed during a reload, you can even move NATed clients from one=20 >>> public IP to another, without them noticing. >>=20 >> We would prefer to stick with ipfw. The most common documentation I've >> founded is natd+ipfw. I've also seen pf+ipnat. I haven't really seen any >> documentation on ipfw+ipnat. Is this possible? Or would we be able to do >> ipfw+pf+ipnat? What solution would scale best to 1500-4000 authenticated >> users? > > I have used ipfw + pf for almost a year, for about 400 clients and I=20 > am very happy with it. Note that I only use ipfw for dummynet. In=20 > all other situations I only use PF. > > PF uses a binary tree to store NAT states, so it isn't really=20 > affected by the number of clients. It also features state timeouts=20 > reduction based on the number of NAT states, which is very useful if=20 > one Windows station gets a "lets scan the whole /16" virus. I received a response off-list (to which I replied on-list) from somebody who said the pf binat solution doesn't scale will beyond 500 clients. We currently have over 1500 public IPs that could be in use,=20 and we may eventually have more than 4000. Can anyone confirm this=20 limitation?=20 --=20 Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley --RNYIsZSUNfbU4BwD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBRvhQ6iPHEDszU3zYAQKYgw//S6beV0UEc4cXrmRVy6uH3fCS8kzzDbSK 9kTSUXBl6DHixGRwoZ2dUn1RYEiMX4A1ftsSdvTn1UGuohUrrceoOlY6tFHBSzzH o0Ei/33Jl1OTbSU0R0q7HbEasihMu1DtK8yrRPX+GfIIH5o6AHs06+EWuJjdaDd1 Az2lxonQKqkzrEAAz+VOjnA2s/vClVB48/k5q0VHEjnN8NB5HOz4hqBqFt46brTz X+JB5N99IPIjwpSKmlQLQAd9cInb0e1wb+OjTWUZGQOyc8Fb9yBOHYsQ52oY8Q0e SLWCgBmaj8iBCkyj0qxP712HvUkDuvxiIc7O6ETvMb4svI8UyOi1n+IEGNldKbDK iMIgLamXAQUbZ1x6DXyDxAhEFQns10VmK00flzXQQK0V9pn5Zd1d2yHfOjvbDU1q 4kDwX125qsijaNGLRgoBxwcXOUzRhJh8hRiDyxSUn4hDvGWDayEJ95BndK/hieFZ N4oDj+ABS372X2pxJIia0XPXVwcKIRw3tv5vRlSlGYdz32k9ymzyH/aPvjP1jWxr oAwdVk/WhBJIZMx6V4gK//uK2zmzZnetp3ktb0RGCGoDmkQi7QfY+fTH9G/bkRon i8bbpA6SI65GRgyLKzdOhTlN8HMiUa7fx55fEqasXI44vDxdnTo1vVe3z+txB8v7 1b90WqNF1/Q= =DwhU -----END PGP SIGNATURE----- --RNYIsZSUNfbU4BwD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070925000602.GT19429>