Thanks Norm, really appreciated. Just to be clear and make sure that I am understanding your setup (high level anyway)
1. student joins wlan and is presented with captive portal 2. student logs in to the captive portal 3a. if first time logging in, student is assigned 4 internal IP addresses (per building) and DHCP reservations are configured in the DHCP server(s) and device gets address from the reservation. 3b. If not first time logging in and reservation exists for this device, device gets address from reservation 3c. if not first time logging in and no reservation exists for this device, a new reservation is configured for the new device (up to 4) and device gets a lease. 4. student does their thing on their device, probably Netflix or some such. Maybe even school work. 5. NAT translations/streams are logged and if needed can be traced back to an internal IP. 6. based on the internal IP reservation, you know the student. Anything that I have missed? Do I assume that you clear your reservations on a yearly or semester basis? Cheers, Jeff -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Norman Elton Sent: Tuesday, February 24, 2015 7:57 AM To: [email protected] Subject: Re: [WIRELESS-LAN] NAT tracking question 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/.
