Jerry,
You told mnet before about using simply the setings in SMs to control bandwidth. Did you know of a way to secure the APs(as in prevent rogue SMs from connecting) without BAM? Thanks in advance.
Our ISP has no authentication. Therefor anyone could get an SM and leech bandwidth. We have been looking into a non BAM way to take care of this. I would like to setup a linux PPPoE server, but currently lack the skills on said setup.
We do in fact use BAM (in Prizm), but that’s only one of the ways we prevent rouge users.
The system I have in place is a Linux box with two ethernet interfaces in it. I route a private IP network across it, and I have a NAT rule for each client. I do not run DHCP, I manually assign addresses to each radio at installation.
The additional benefit I gain from this is that if a client is not paying, I don’t just shut off the connection. I block all forward packets from the client and hijack all port 80 traffic to a web server process on the linux box that basically says “Hey, you no paya da bill, you no surfa da net” That way we don’t get clients thinking something is broken, they know they will have to pay to reactivate the account. Works quite well for us in that respect.
Bottom line: without BAM you can’t prevent them from connecting, but you can keep them from your bandwidth with the right approach.
That sounds pretty clever. Does that mean you’re running your radios all in nat mode? if so does that affect your voip and vpn capabillities?
I like the idea of having your system compartmentalized, as opposed to centralized as the current BAM setup would do. If you have a problem on your network, say with icmp flood, it would stop at that tower. To me this means tower routing, and possibly even AP managed authentication. One chink in the plan is the issue of a rogue SM, but your idea sounds like it could possibly be implemented at an individual towers on a network,however correct me if I’m wrong…please. :?
You could use a Static ARP table or have router rules to only route packets from known MACs.
Question can you not set the Auth Key in the AP it’s self? I know there is a spot for it. What if you imput the key there and then input the same Key in the SM on the Config page?
I’ve never tryed it, qurious to know if that would actually work. Has anyone actually tryed it?
Yes, we use mostly (98%) NAT. In a few situations, we have the real IP on the client equipment, but then I’ve still got the ability to hijack and block that traffic at the border router. I am only using one central router for my whole network right now, as all of my remote locations are grain elevators.
Everything comes back to my office where our primary tower is ,and my CMM basically plugs into eth1 on the linux router. Eth0 plugs into my main switch, All clients get a private IP in the 10. space, which NATs to thir real IP at this router. It basically looks like this:
Real IP --> 10. Canopy network ruter NAT --> SM NAT Class C
We have had no issues with double NAT except in a few cases of World of Warcraft players. They already had Linksys routers, so we put the Public IP directly on their Linksys, explaining that they were losing a few effective layers of “firewall” (I guess NAT can be thought of as the same net effect as a firewall, can’t it?), but they were still protected by the Linksys router. I can also still provide the same “Locked for lack of payment” experience as the rest of the network.
We do actually use Prizm/BAM to prevent rouge SMs and for performance history.
As for VOIP and VPN, we do not use the high-priority channel as of yet, and we do have a number of onage-type VOIP users who are quite pleased with their service. VPNs are a problem witht he NAT in the SMs, so yes, a few of the cases have required the SM to bridge, but in those cases we are employing another Linksys or similar device for the client network.
I’m not a fan of bridging, it has always seemed to me to pose as many problems as solutions in a situation where you do not actaully want shared network space. The only conceivable advantage I can wrap my brain around is simplicity of network design. The price you pay just seems too high for my taste.
I welcome corrections/comments to the above paragraph of opinion. I’ve always wondeed if simplicity of implementation was the driving factor behind most manufacturer’s designs. Or is it actually easier to implement bridging in the radios from an engineering perspective? Anybody know? Either way, I applaud Motorola on the inclusion of the NAT feature, it has really made it easier/less expensive for me to implement a network that I’m happy with. Our first foray out of 802.11 duct-tape-and-bailing-wire-land (we started wireless stuff in 1999 (low bow to Marlon Schaefer)) was with Trango 900MH gear, and we put a Linksys at each client site at our cost so that we could route (ok, NAT, but the network segmentation effect is the same) instead of dealing with the bridge.
My clients have appreciated the extra layer of security provided by not having a public IP on their computers and it has been a selling point over DSL and cable in our area.
Sorry for the rambling on, it’s been quite a ride here with the weather in Central Illinois.
Anyone else spend all day yesterday knocking an inch of ice off of client antennas?
Here’s to praying for enough sunlight to finish the job… 8)
Frothingdog.ca:
I don’t think it will work, because unless you have an authentication server, authentication will be turned off, so the key should be irrelevant, right? I’ve never tried it either, anybody else?
Well what if you set the Config Source to “SM” instead of “BAM” in the AP?
But the odds of it working are slim. Because it would defeat the perpose of deploying Prizm. So I dought Motorola would let that work.
But it would be a nice feature. Authentication via a Security Key (sorta like a WEP Key) between SM and AP without the need of Prizm.
Sorry, didn’t see this earlier
We do not deal with authentication, all customers are static routable IP’s. Connecting to the AP only gets them on the network. Without the IP information they are stuck.
If they are smart enough to figure out how to connect, get an IP and surf, it won’t last because we audit IP’s monthly and any new IP’s that are not documented would be considered rogue.
I like cvs’s solution. It’s pretty smart.
At some point we will need to manage the elements and we will likely go with Prism. I am not much into experimentation, I’d rather use something that works out of the box, we just need to justify the cost and right now we can’t.
CVS :
You indicate that VoIP is working with NAT? I have been unable to make VoIP(SIP) work with the SM NAT. Did you have to do anything special to make it work?
tlsarles:
Not a thing. I didn’t even know about the first one until the client came in to pay his bill and was waxing poetic about Vonage. We are not using high priority at this time, though we are considering adding it as an option for an additional fee. I know of 6 clients I can think of off the top of my head using VOIP and we’ve got no complaints. Everybody seems happy with it.
We have not attempted yet to set up a SIP connection using Asterisk, but that will happen right after the first of the year. I’ll be interested to see if we have issues then…
cvs wrote: All clients get a private IP in the 10. space, which NATs to thir real IP at this router. It basically looks like this:
Real IP --> 10. Canopy network ruter NAT --> SM NAT Class C
We have had no issues with double NAT except in a few cases of World of Warcraft players. They already had Linksys routers, so we put the Public IP directly on their Linksys, explaining that they were losing a few effective layers of "firewall" (I guess NAT can be thought of as the same net effect as a firewall, can't it?), but they were still protected by the Linksys router. I can also still provide the same "Locked for lack of payment" experience as the rest of the network.
Would you explain what you mean/how you did it, when you said
so we put the Public IP directly on their Linksys
Thank you.
The public IPs are on the router that does the NAT. All I do is turn off NAT in the SM and put the public IP on the Internet port on the Linksys router. This effectively result in the following change:
Physical traffic flow:
Internet <----> Router <----> AP <----> SM <----> Linksys <----> PC
Addressing changes from this:
Internet <----> Router <----> SM <----> Linksys <----> PC
^----Public -----^^–Private–^^–Private–^^–Private–^
To this:
Internet <----> Router <----> Linksys <----> PC
^-----Public address-----------^^------Private address----^
I’m not sure if this answers your specific question or not, but that’s the logical change.
cvs wrote:
To this:
Internet <----> Router <----> Linksys <----> PC
^-----Public address-----------^^------Private address----^
I'm not sure if this answers your specific question or not, but that's the logical change.
That's what I thought you had said, but what I don't understand is how are you bridging the "Internet/Public address" subnet across the Router to the Linksys? Or, are the IP addys in question actually in different subnets?
Oh, I think I understand what you are asking. I also see how what I drew for you was misleading. We have a separate class C on the router just for the wireless network (I’m about to add a second one…). That’s the address that goes onto the Linksys.
So we have this:
Border router <----> wireless router <----> AP
^----Admin network----^ ^----Client network----^
The wireless router would normally NAT the private address on the SM to the public address that the client will appear to come from out on the Internet. We do one-to-one NAT. In other words, my normal setup has this:
Client address: 10.x.x.210
NATted address: 65.x.x.210
In the case we are discussing, I remove that particular NAT rule on the router and configure the SM to bridge. That allows the Linksys to be in the collision domain of the router, thereby allowing a direct (ARPable) link between the router and the Linksys.
Clear as mud?
I was thinking “one-to-one NAT”, but decided that couldn’t be it … 
Yeah, we’ve dealt with three or four US Customs subpoenas for child porn and other stuff in our 10 years as an ISP. We built our first wireless network in 1999 with one-to-many NAT to save address space, and then I ran into the situation that required us to ID a customer to the traffic in question, and we couldn’t do it. One-to-one NAT for us from now on.