Christopher Cowart wrote:
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
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.
Are you sure it doesn't just mean you need to keep logs of who was
NAT'd to what at any 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.
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?
I don't think we have the ability to do that.
it may take some coding on your part.
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.
never heard of such a setup.
I suggest you find out if that is the only solution your security people
would accept. (As someone doing security stuff for a few years I think
that someone is confused somewhere).
Thanks for your help,
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
