Here's a write-up I did a few months back. I'm happy to elaborate as needed!
Norman Elton College of William & Mary ========= We recently converted to NAT, to solve two issues. The obvious is the growth in wireless devices. Our five /21s simply couldn't keep up with the demand, and we got tired of shoehorning extra subnets to accommodate. We were also concerned with the amount of broadcast traffic, which being sent at the lowest supported data rate, was needlessly occupying airtime. We knew some sort of NAT was in our future, and we wanted it partitioned down to the building (or region) level to contain broadcast traffic. But our security folks were apprehensive about tracking usage. Even with flow logs, responding to a DMCA complaint could take a significant amount of research. We brainstormed, whiteboarded, and head-scratched. Wouldn't it be nice if each student had exactly one public IP address, which front-ended whatever devices they had on campus, where-ever they were located? This would require some sort of deterministic NAT, whereby the NAT appliance knows the owner of a particular internal IP address, mapping any outbound traffic to the public IP address associated with that user. Here's how we got there... Each building (or region) is assigned a /16 within 100.64.0.0/10 (reserved for CG-NAT). So, Jones Hall would be 100.72.0.0/16. A student computer, upon being authenticated to our NAC system, is immediately assigned an IP address within every building's /16. In fact, they are assigned the same last two octets across our entire campus. So a student roaming across campus would get 100.###.154.24, where the second octet corresponds to their local building number. When we assign an address to a device (say, 154.24), we reserve a block of four contiguous IP addresses for that particular user. So if their laptop, being seen first on the network, gets assigned 154.24, their iPad might get 154.25, their phone would get 154.26. If they need more than four addresses, we reserve them another block. Remember these assignments represent the last two octets of the device's IP address. The first two are dependent on the building (100.72 = Jones Hall, etc). All of this IP address logic allows the actual NAT to run very fast, with very little logic. The outbound NAT is handled by an F5 Local Traffic Manager, in our case, a 4000S. This box can handle very rich NAT applications using their iRules. In our case, it uses a simple mathematical algorithm to examine the incoming IP address, mapping each block-of-four internal addresses, regardless of building, to a single public IP address. It sounds complicated, but it boils down to 10-12 lines of iRules logic. The magic is really the glue between our NAC system and our DHCP servers. As soon as we learn the ownership of an onboarded system, we determine an IP address and jam it into our DHCP server. The vast majority (96%) of our students have four or fewer devices. So they occupy a single block of contiguous IP addresses. A small percentage have five or more computers, so they actually are given two blocks of addresses, which correspond to two public IP addresses. Admittedly, this is hard to explain. It takes a few passes. And we were a bit apprehensive about how it would scale. But, surprisingly, it's working like a champ. No timeout values, no indeterminate NAT. Room for growth. No need to dive into flow records, our security folks are happy. The only hiccup, and it was not unexpected, involves supporting game consoles. Unlike your home Linksys router, the F5 does not support uPNP. This will likely impact anyone doing NAT on an enterprise firewall. Some peer-to-peer games do not work. But since a particular game console is always assigned the same public IP address, we can configure an inbound NAT rule for applications that use fixed ports. This comes up VERY rarely (maybe three or four times so far). On Tue, Feb 24, 2015 at 9:33 AM, Oliver, Jeff <[email protected]> wrote: > Hey Norm, > > For those of us with limited IP space, this sounds really interesting. Not > sure if it belongs on the listserv or not (feel free to contact me off-line) > but I am interested in your setup/config and would like to know more about > it. Would you be able to supply some details? > > --- > Jeff > > > > From: Norman Elton <[email protected]> > Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv > <[email protected]> > Date: Monday, February 23, 2015 8:11 PM > To: The EDUCAUSE Wireless Issues Constituent Group Listserv > <[email protected]> > > Subject: Re: [WIRELESS-LAN] NAT tracking question > > We deterministicly NAT up to four devices for an individual user to a single > public IP. As our typical user has less than four devices, it works out that > most students have a single public IP assigned to them. Should they > authenticate a fifth device, a second IP is assigned to cover devices five, > six, seven, and eight. The effect is that we've quadrupled our IP > utilization. > > It's mostly a matter of handing out predetermined IP addresses which include > a series of bits used to identify which "group of four" it should be NATed > to. Our F5 box can examine the private IP, do a little bit shuffling, and > calculate the corresponding public IP. This calculation is extremely > light-weight, allowing the whole system to scale quite well. The heavy > lifting occurs when the device is on boarded the first time, at which point > a "group of four" is allocated for the user. > > Norman Elton > College of William & Mary > > > On Monday, February 23, 2015, Chuck Anderson <[email protected]> wrote: >> >> If you have 1 public IP address reserved for each individual user, why >> do you need to do NAT at all? This is a serious question--if you >> aren't saving public IPs by doing 1:many NAT, why do NAT at all? >> >> Thanks. >> >> On Mon, Feb 23, 2015 at 11:33:45AM -0500, Norman Elton wrote: >> > We play tricks with our ISC DHCP server and a pair of F5 LTMs (similar >> > to the A10 gear). The DHCP server hands out predetermined private IP >> > addresses to devices as soon as we determine ownership (through our >> > NAC). For outbound traffic, the F5 uses this private IP address to NAT >> > to a public IP address that is reserved for the individual user. The >> > end result is that no matter where the device is on campus, we know >> > that 128.239.x.y is something owned by Joe Smith. If we need to know >> > exactly which device, we consult our flow logs. But at least we're 99% >> > confident we're dealing with the right student. >> > >> > I'm happy to share the gory details if someone wants to wrap their >> > head around it. >> > >> > Norman Elton >> > College of William & Mary >> > >> > >> > >> > On Mon, Feb 23, 2015 at 10:30 AM, Danny Eaton <[email protected]> >> > wrote: >> > > We've got our Juniper SRX 5800 doing our NAT for all wireless, plus >> > > all students and visitors (wired or wireless). >> > > >> > > We send those logs (and the SRX is VERY CHATTY about NAT) to our >> > > Splunk server for the tying together of date/time, public IP and private >> > > IP >> > > - in the event we get a notice from some TLA. >> > > >> > > -----Original Message----- >> > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv >> > > [mailto:[email protected]] On Behalf Of Heath Barnhart >> > > Sent: Monday, February 23, 2015 9:12 AM >> > > To: [email protected] >> > > Subject: Re: [WIRELESS-LAN] NAT tracking question >> > > >> > > We use a Sonicwall E8500 for NAT, it will log all NAT translations and >> > > send them as syslog to a server for storage. I have logrotate changing >> > > files >> > > every hour to make it easier to search on. >> > > -- >> > > Heath Barnhart >> > > ITS Network Administrator >> > > Washburn University >> > > Topeka, KS >> > > >> > > >> > > On Wed, 2015-01-14 at 14:49 -0500, Jerry Bucklaew wrote: >> > >> To ALL: >> > >> >> > >> We have a large Cisco wireless deployment with public ip address >> > >> space. Getting more public IP's is getting difficult so we are >> > >> considering going to NAT. The issue we have with NAT is that we >> > >> still >> > >> want to be able to map an outside IP back to a individual user. Once >> > >> you go to NAT that of course becomes more difficult to do. I know a >> > >> lot of you are probably already doing this and I was wondering how >> > >> and >> > >> what products do you use? I assume most have a one to many NAT and >> > >> then >> > >> use something like a netflow collector to to track the inside NAT IP >> > >> to >> > >> the outside Src-IP/DST-IP/Port/Time. Any good working solutions or >> > >> products would be helpful. >> >> ********** >> Participation and subscription information for this EDUCAUSE Constituent >> Group discussion list can be found at http://www.educause.edu/groups/. > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
