Re: Large-scale 1-1 NAT
- From: Christopher Cowart <ccowart@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 24 Sep 2007 13:55:44 -0700
On Mon, Sep 24, 2007 at 01:26:13PM +0400, alexzimnitsky@xxxxxxxxx wrote:
original:
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.
do your security foulks want connections to be identifiable
outside-in or inside-out? If inside-out then netflow before single
ip nat should do the trick
Complaints from the outside world must be traceable to a single
individual behind the NAT. This is a significantly easier, especially in
automated case handling, when only one person is using a public IP at a
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?
we used pf to binat people (in parallel with ipfw to filter them).
How are you going to nat them (ipf, pf, netgraph)? Updating rules on
the fly was as simple as reloading them (no disruption to existing
pf states). Netgraph nat states behave similarly. The real problem
with pf binat was when we had about a hundred binat rules it almost
halted the traffic through the router.
Are you suggesting that a pf solution isn't going to scale well on the
order of 1500 clients? We may even get additional public address space
to support 4000 or more clients. Will netgraph scale better?
It doesn't look like there's any way to have a running natd update its
configuration without restarting. That's obviously disruptive.
use ipfw+netgraph instead
So you recommend ipfw+netgraph? We don't have any experience working
with netgraph. I see ng_nat(4), but if anyone could point me to a more
thorough howto, I'd greatly appreciate it.
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).
you are right. It is not.
My expirience is it is bad idea to even have more than a couple of
doezns binat rules in sequence (although i tried it with pf, not
with netgraph).
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.
my ploblem was how to not reserve large number of small address
pools in advance and use a single pool of /22 to number customers
belonging to many different physical segments (even living behind
different routers).
i used binat first but it scaled badly, so i found a better
solution. I guess you problem is different.
What do you mean? We do have 3 discontiguous subnets (/22, /23, /26),
and may add one or more /22 or /23 subnets in the future, so we
definitely need the ability to pull from various pools. Our NAT box
will be attached to a trunked interface and use vlan interfacess to
reach the routers for each of the subnets.
Thanks for your experiences trying to get binat to scale -- we were
definitely considering the pf+ipnat solution.
--
Chris Cowart
Lead Systems Administrator
Network & Infrastructure Services, RSSP-IT
UC Berkeley
Attachment:
pgp0wy1W9LJZD.pgp
Description: PGP signature
- Prev by Date: Re: Large-scale 1-1 NAT
- Next by Date: Re: Large-scale 1-1 NAT
- Previous by thread: Re: Large-scale 1-1 NAT
- Index(es):
Relevant Pages
|
