Re: Large-scale 1-1 NAT

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 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.
We used to have this problem too, for some NATed networks. The
solution which 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.

I must admit I haven't thought of this. With this new information I
am missing a point. Since you need to make a 1-to-1 association
between clients and public IPs, why do you need the NAT at all. Is
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
words "authentication web page". This made me think you are
establishing a captive portal, which is not secure at all. If I
understand well the authpf solution would be secure, except perhaps
a small delay. You might proxy your clients to a "click here and
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
public IP 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?

I have used ipfw + pf for almost a year, for about 400 clients and I
am very happy with it. Note that I only use ipfw for dummynet. In
all other situations I only use PF.

PF uses a binary tree to store NAT states, so it isn't really
affected by the number of clients. It also features state timeouts
reduction based on the number of NAT states, which is very useful if
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,
and we may eventually have more than 4000. Can anyone confirm this
limitation?

--
Chris Cowart
Lead Systems Administrator
Network & Infrastructure Services, RSSP-IT
UC Berkeley

Attachment: pgpkQQf5s99Tt.pgp
Description: PGP signature

Relevant Pages

  • Re: Large-scale 1-1 NAT
    ... these hosts might NAT to a single ... authentication page. ... we expect to max that out (1500+ clients). ... I suggest you find out if that is the only solution your security people ...
    (freebsd-net)
  • Re: WCF Message Security Problem
    ... Ok with a LOT of fiddling around with certificates and security ... If the username and password authentication fails the clients channel ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Hotspot Security in 30 minutes?
    ... Only if you have already finished setting up the VPN your clients are ... going to use for secondary security and authentication. ... you said 'hotspot' not 'access point'. ... give the appearance that you care about security to your clients. ...
    (Security-Basics)
  • Re: Webapp Authentication best practice...
    ... These are clients that are accessing the Web app via the INTERNET. ... so you can't use Windows authentication. ... In that case, you have a serious security issue, it's your job to authenticate incoming users in the strongest possible fashion, failing to do so leaves yourself wide open to attack! ... I doubt that it is good practice to capture and retain their credentials ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: pine program and mail services with FC6 System
    ... protocols = imap imaps pop3 pop3s ... # Directory where authentication process places authentication UNIX sockets ... # chroot login process to the login_dir. ... # what most of your IMAP clients are. ...
    (Fedora)