Date: Mon, 24 Sep 2007 13:35:16 -0700 From: Christopher Cowart <ccowart@rescomp.berkeley.edu> To: freebsd-net@freebsd.org Subject: Re: Large-scale 1-1 NAT Message-ID: <20070924203516.GQ19429@hal.rescomp.berkeley.edu> In-Reply-To: <46F77C27.9050400@net.utcluj.ro> References: <20070924072517.GL19429@hal.rescomp.berkeley.edu> <46F77C27.9050400@net.utcluj.ro>
next in thread | previous in thread | raw e-mail | index | archive | help
--6JKsAUbrJhuSllgx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 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. > >We used to have this problem too, for some NATed networks. The solution wh= ich >has been adopted is to capture the flows on the gateway and send them the >security team. The netflow protocol is very well suited for this. 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. >>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 public I= P to >another, without them noticing. 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? --=20 Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley --6JKsAUbrJhuSllgx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBRvgfhCPHEDszU3zYAQJ6pA/+NRNqxCImYwNd9Ovhl6eTM+v2JgfIGTnY +EEO+urvaia0YtSh7R3jsW+lbLSEAqd0LIn6Zien88cCqznVNo7VEM9ZoMcmVQCQ U/232xI7KV4BkaFoZHpkUvw+4RRsmWXJm5k8z/G7/xkj2stoz8cQmYmR2ycVLnWb RhoMD5LH7tEGqp2Zs+yd2+SSu426J7XGymDWTIIL36Iw/MthS52/O+P0nMYzPqtG aP8vS+n0yuAbEFonTwd+800iN+NM69K06RVVgaKPWGC+JBCyIu6JovssmW+t4sQ/ Fj6+IappcLw+T0noun2G4H9USjGTLtfBDuXSprCWwCJFiOYa8zKL/GQMECkdm1KL sRipptgCyENpSYNWp6WXh0Pw5Ds+XU0o9d7bR/aY7TVhOQYKYwhMT/nbGU1Iv1wS 0kA87myF1+IU+1u5jZ0hmubctaOaVvE7NolQ66Fp0TcETIC5QWW6ashxvTRvfkv5 TfXL9yDdjHNdbe8vPPVOzuFjF3hY9GsNBHER9f5Q3Wkj7mhos3xWj7cfTd2I5ES1 oG3k4I5V1BJuL9lc4sXfhexsqoVrp2LUQ/N7hXig9C8A6wAUS54BrSEhIrNJL+rP e3LxGdOHNVFSBb8xf6WLrzQ+MCRoz7uFiGOjdEsCE4bigoiHKdaflJvBDwDH8z2c yU5qX66EJnI= =Aw9q -----END PGP SIGNATURE----- --6JKsAUbrJhuSllgx--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070924203516.GQ19429>