We are strongly considering enabling NAT on all our customer’s SMs on our heavily populated APs. We’re hoping that by turning this on it will reduce network traffic and essentially free up some throughput on our APs. Two questions:
1) Does this sound like a viable plan and outcome?
2) Assuming we go ahead and turn on NAT, what are some of the common complaints from customers regarding ports not being opened and such? I’m assuming bit torrent will not even work? What other common complaints/requests do you hear?
Are you connecting customers directly to your network or do you require a router at the customer end? If you have customers directly connected you will definitely want to enable NAT on those users. If the customers have a router then there is no value in enabling NAT in the SM.
Are you currently using the sustained/burst settings? You can go a long way toward BW control with just the QOS settings in the SM.
We don’t do residential. If we did we would absolutely use PPPoE and bandwidth shaping to control utilization.
We don’t require routers, I would guess that more than 50% of our customers do use them.
We’re figuring to just turn on NAT and if they have a router, so be it. If they don’t have a router then this should help with some traffic.
We’re starting to get Prizm installed and learning it so I’m sure a combination of enabling NAT and trying out different QoS settings will help us with bandwidth. Currently we require all our installers to set specific settings for the QoS tab.
95% of our customers are residential also if that makes any difference.
I’m not sure if enabling NAT is going to free up traffic for you. Far as I know, NAT by itself isn’t much of a firewall, if that’s your intended effect. Might prevent some unsolicitated incoming stuff I guess?
As for expected troubles, I enable NAT and the DMZ address in every radio I set up (not sure if this is a good thing or a bad thing), that way I can tell a customer what IP to use if they do have a problem. Voip software (particularly Teamspeak), Xbox360’s have the most trouble negotiating NAT, and setting the customer to the DMZ address solves this usually. If the customer has a router, I also send it through the DMZ address too. Like Jerry hinted at, this is entirely redundant, but I do it for consistency.
pcpolo wrote: Assuming we go ahead and turn on NAT, what are some of the common complaints from customers regarding ports not being opened and such? I'm assuming bit torrent will not even work? What other common complaints/requests do you hear?
We enabled NAT+DHCP on SM for 95% of our customers (mostly residential).
This allows the customer to easily connect more than a computer without specific settings.
Some more issues arise when you are implementing double natting (on your core router + SM).
The main problems are:
1) P2P applications (like Emule) not fully working (e.g. Emule connects with "low ID") - This is not necessarly a bad thing for us ;-)
2) PPTP VPN client is not working (due to bad Motorola nat implementation). IPSEC VPN client is working if NAT is only on SM (not double)
3) Some users accessing free services (like Rapidshare) could be limited because of shared IP with others
4) Gaming online could be affected (e.g. Xbox360)
5) Of course any application requiring public IP is blocked (mail&web servers, point-to-point VPN, etc)
For some advanced users we configure the SM in bridge and put a router on client side (managed by us to avoid possible issues).
BTW, I don't think using NAT will free bandwidth. It can just stop broadcast traffic: is that your problem?
If you can, I strongly recommend PPPoE for residential users for a number of reasons:
- IP addresses are cheap. We bought a new /20 from ARIN this past year for only $3000. That’s around 60 cents per IP address.
- Power users love being able to control their own port forwards.
- UPnP on their routers just works
- VPNs will work
- No Double-NAT issues
- Provides the benefits of a dynamic IP
- Allows us to sell them a static IP 
- Any static IP or routed subnet is portable anywhere within our network without any effort on the network side
- Reduces support effort since our equipment is just a layer 2 bridge: we will do basic router setup but for any other problems call the manufacturer
- CPE replacement is very simple
- Username is portable between DSL, Wireless, and Dialup
- Same login as our client portal so they can administer their own emails, do spam filtering, etc
- Very easy to apply traffic shaping and transfer quotas
- Easy to disable accounts & force them to a walled garden
- Only one router (for us anyway) that has to be managed for customer access
- Most of your network ends up being switches and bridges back to your core
- Easy to lock down your transport network to PPPoE frame types and cut out crap from customers equipment
- Don’t need to mandate a router on customer’s side, cutting down initial setup costs
- A lot easier to notice link issues since the PPPoE session can drop
But of course there are drawbacks with PPPoE, too:
- Client not built in to old OSes (Win2K or MacOS 9 or older)
- Weird stuff can happen when Windows breaks… (“netsh int ip reset reset.log” tends to fix)
- Customers have a tendency of disabling their NIC in XP instead of disconnecting PPPoE
- People have to type in passwords, which is to say they have to type… “No, ma’am, the numbers are not upper-case. Right. Lower-case numbers. Don’t use the Shift key.” A handful of our accounts have pwds like “123456”
- To really take advantage of low-maintenance operation you need gear beefy enough to centralize your aggregation.
- Over large areas will require VLANs to some extent, you may have to fork out for decent switches if you’re currently running “pro-sumer” grade stuff that has no management or layer 2 features
- Needs a RADIUS system with a database - and they gotta be reliable
- People filling in the “Service Name” field… aaarrrrgh
- A lot easier to notice link issues since the PPPoE session can drop
Also, there are some things you can do to improve performance on a routed (or broadcast…) network:
- Use Prizm to apply filters to your SMs to stop broadcast garbage - the only “real” broadcast traffic should be ARP. You’d be surprised what sort of weird configurations blast out crap (for example, I saw one customer blasting out NetBIOS Name Service over IPX quite a bit)
- Set up some QoS bandwidth controls on your links. Fiddle with sustained and burst rates for what you feel is fair (either morally or contractually ;-)) and makes things run smooth.
- Enable SM Isolation on all of your APs
- Toss in some VLANs
- Within the same VLANs, most switches will let you set a “protected” or “private” port. This is similar to SM Isolation on an AP. The switch will not pass traffic between these ports. This is really great if your APs terminate into something that can do this. A company we bought put up a lot of Tranzeo stuff. On the TR-6000s we turned on CPE Isolation, slapped in VLANs to different tower sites, and added “port protected” to the switch configs. Presto, now a given customer’s frames can only make their way back to whatever gear we have in our core instead of going out over a 3000 sqkm broadcast domain.
Hope this helps!