Cheap LSN/CGN/NAT444 Solution

Mon Jun 30 12:06:51 UTC 2014

On 30.06.2014 14:12, Roland Dobbins wrote:
> I've seen huge problems from compromised machines completely killing
> NATs from the southbound side.

It depends on CGN solution used. Some of them will just block new
translations for that user after reaching the limit, and that's it.

On 30.06.2014 09:59, Skeeve Stevens wrote:
> I am after a LSN/CGN/NAT444 solution to put about 1000 Residential
> profile NBN speeds (fastest 100/40) services behind.

> I am looking at a Cisco ASR1001/2, pfSense and am willing to consider
> other options, including open source.... Obviously the cheaper the
> better.

ASR1k NAT is known to be problematic (nat overload specifically), don't
know if they fixed it yet. I recommend to check this with the vendor first.

New Juniper MS-MIC/MS-MPC multiservices cards can be used but
feature-parity with MS-DPC isn't there yet. For example, you can have a
working CGN with most bells and whistles, but you can't use IDS. You can
(probably) use deterministic nat with max ports/sessions per user, but
sometimes it's not enough. Again, ask the vendor for
details/roadmaps/solutions.

Both those options aren't really cheap though.

Cheaper would be something like Mikrotik but I wouldn't touch that sh*t
with a ten-foot pole. It might work but you'll pay for that with your
sanity and sleep hours.

Speaking of cheap and open-source, I know several relatively large
implementations using Linux boxes. One Linux NAT box can chew on at
least 1Gb/s of traffic, or even more with a careful selection of
hardware and even more careful tuning, and you can load-balance between
them, but it's much more effort and it isn't robust enough (which is the
reason why they all migrate to better solutions later).

BTW, I agree that you should speak in PPS and bandwidth instead of
number of users, those are much better as a metric.

> This solution is for v4 only, and needs to consider the profile of the
> typical residential users.  Any pitfalls would be helpful to know -
> as in what will and and more importantly wont work - or any
> work-arounds which may work.

Try to pair a user IP with a public IP, that way you'll workaround most
websites/games/applications expecting publicly visible user IP to be the
same for all connections.

Start with selected few active customers, check how much connections
they use with different NAT settings. Double/triple that. Then do the
math of how many ports/IPs you need per X users, don't just guess it.
Then try to limit it and see if anything breaks.

By working with them you can also workaround some of the problems you
didn't think about before. Seriously. Fix it before you roll it out.

What anyone implementing CGN should expect is complaints from users for
any number of reasons, like their IPSEC or L2TP tunnel stopped working,
or some application behaves strangely and so on. Prepare your
techsupport for that.

> This solution is not designed to be long lasting (maybe 6-9
> months)... it is to get the solution going for up to 1000 users, and
> once it reaches that point then funds will be freed up to roll out a
> more robust, carrier-grade and long term solution (which will include
> v6). So no criticism on not doing v6 straight up please.

Heh. Nothing lasts longer than temporary solutions. You should implement
it like you're going to live it for years (probably true) or you'll
create yourself a huge PITA very soon.