Here is a complete shot i n the dark question for PMP450M. I've scoured the manual and not really gotten anywhere.
Can a SM have two IPs associated to it from two different networks? We have providers using our APs so they assign their own network IP address, but we are trying to also manage from the same network the AP is on. I have visability into the SMs now through the AP, but could I access the SM without going through the AP?
I realize I could alter routes and just allow the two to talk openly, but we are trying to avoid that.
If you're using NAT on the SM, then yes... you can have an external NAT IP, and a separate or shared management IP.
There's probably ways to do this with PPPoE or using seperate VLAN's for user and management traffic... but we don't use either one, so I don't have any examples for you.
Okay, NAT is promising, but I think we are trading one issue for another. If we change the management VID to our local management our providers lose access on their network to remotely log into the radios. It may come down to choosing the lessor of two evils.
@kendali wrote: Okay, NAT is promising, but I think we are trading one issue for another. If we change the management VID to our local management our providers lose access on their network to remotely log into the radios. It may come down to choosing the lessor of two evils.
They could still use the backdoor through the AP to do SM management. I'd also highly recommend firewalling various http/snmp/telnet ports of any Cambium radios you have with public facing IP addresses. You could also do a hybrid... use public IP's for the NAT interface, and then use private IP space for the management interface.
In my experience NAT isn't the silver bullet. I can't remember if it breaks PPPoE bridging (it might). If you guys aren't already using NAT on the SM you won't like what happens once you start ;)
My suggestion is to create a new VLAN for managing third-party SMs. Give it a new subnet and make only that subnet reachable to both your network and the wholesaler. Access for everyone!
We toyed a bit with NAT, but it is so different then what we have been doing for the past 15 years with pmp100. We were looking at doing this double IP thing so we could utlilze cnMaestro, but the program is just not there for how our network is set up. Looks like we are going to go the radius route and use our current NMS for managing.
Haven't played with cnMaestro yet. Since we run so much PMP-100 still I don't see any point in it. However, there's an "on site" version that should work with whatever you're doing.
I've been running RADIUS since Prizm was retired. Very happy with how I've got things work and am planning writing my own software to do the rest so we can finally get rid of Wireless Manager.
Haven't played with cnMaestro yet. Since we run so much PMP-100 still I don't see any point in it. However, there's an "on site" version that should work with whatever you're doing.
I've been running RADIUS since Prizm was retired. Very happy with how I've got things work and am planning writing my own software to do the rest so we can finally get rid of Wireless Manager.
On site does not support multiple NICs for.
We are still using BAM/Prizm with our 100 install, but have already ruled it out for the 450 upgrade we are doing. Are you using RADIUS for bandwidth profiling/authentication and vlan assignment? We almost have it ready to go, but there is quite a lack of documentation on setting this up.
Yes, when an SM connects to an AP, the AP authenticates it to the RADIUS server (two part tunnel... that's the pain in the arse part), and the RADIUS server pushes configuration back to the AP. I send BWSP, VLAN, and IP address information. Getting the server working in the first place is indeed a pain. The documentation I used is from the PMP-320 gear, since that's the first time I set it up. I can dig up some configuration files when I get some spare time if you can't sort it out!
Yes, when an SM connects to an AP, the AP authenticates it to the RADIUS server (two part tunnel... that's the pain in the arse part), and the RADIUS server pushes configuration back to the AP. I send BWSP, VLAN, and IP address information. Getting the server working in the first place is indeed a pain. The documentation I used is from the PMP-320 gear, since that's the first time I set it up. I can dig up some configuration files when I get some spare time if you can't sort it out!
That would be great. Letting my co-worker know to check out the 320 info too. We almost have it, then we can roll out to a real world test.
Well here goes. I believe I sanitized everything appropriately. Anywhere you see "changeme" you should probably change! I removed what I believe to be 'default' files, and nuked similar commented-out configuration. These should just work if you throw them in place, all things considered.
This is done on FreeRADIUS 2.1.12. I'm hoping config syntax is the same on other 2.x versions. The server operating system is Debian. Here are the modules installed:
freeradius
freeradius-common
freeradius-mysql
freeradius-utils
libfreeradius2
I recall installing some "WiMAX" stuff as well, but I don't see it in the list. Oh well.
MySQL 5.5 is providing the database.
So, the basics:
The APs function as a NAS Client. You will see a subnet defined in clients.conf. The password set in there must match the password set on the Security tab in the AP. The AP establishes the outer option of the EAP-TTLS tunnel. In my environment I decided to just accept all outer tunnels from all APs, since it's a controlled network.
The SM's security information gets passed in the inner tunnel. (I think the AP proxies it via the local control network... same one used for the web proxy etc.) Authentication Key is ignored for SMs. The server is (I think, anyway, been a while) set up to strip the domain name. The only information set on the SM is the password and the username. The username is just the SM's MAC address. You'll see "rewrite_sql_user_name" in policy.conf - this strips all the junk out so our techs can just copy and paste the MAC exactly as it appears in the web interface. The database must have a matching MAC address (all caps, no hypens or anything) and matching password defined for the inner-tunnel authentication to succeed.
After authentication then VSAs get sent back, which configure the session. That's where the other junk (note dictionary.canopy and the PMP320 dictionary.dan) comes into play.
I've included sample rows from the RADIUS SQL tables that should help you out. You'll want to set up FreeRADIUS and the database before throwing in the examples.
