Large-scale 1-1 NAT

[Christopher Cowart]

On Mon, Sep 24, 2007 at 01:26:13PM +0400, alexzimnitsky at yandex.ru 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20070924/a42e39ba/attachment.pgp