I was creating an SSID from within the Fortigate to manged Fortiaps and noticed I could not change the security to “Open”. The only options were security options, and Captive-Portal. I was like, where is Open?
You can enable this through CLI
See below for enabling in CLI
just edit your correct SSID name.
SNMPv3 should always be enabled if possible over v2.
First enable the SNMP agent and set the location/device name. Make sure to press apply down at the bottom of the page.
Next lets create the V3 user. You can do this by just clicking “Create New” Under the V3 options.
When you create the user you have options of Authentication algorithms, encryption, the IP of the monitoring host, and what they can monitor. Also, you can drop into CLI and change the source IP for traps.
Last part is now to enable SNMP on the interface you want to connect the monitor to. You only need to have SNMP enabled on the interface the monitor is connecting to, so just do a local LAN interface.
Make sure to click SNMP under the admin access of the interface, and click OK. Thanks it!
Overtime we forget things, especially Shared secret radius keys. This is pretty common, and I run into it a lot. For example – lets say a you setup NPS (Network Policy Server) and a Wireless controller for 802.1x auth, or a ASA doing radius authentication years ago. Some how or another that key was lost – no worries, you can get that back from the NPS server itself.
In just a few simple steps you can get that key back. So lets start by opening up NPS and then selecting “Radius Clients and Servers” and dropping down “Radius Clients”
In this example I am using a Ruckus Smartzone – lets say I forget the password. I can just right click on the client and select “Save and apply as Template.
Next we can create a new radius client by right clicking on “Radius Clients” and once the client info pops up to fill in, we will select to create it from the template, and select the template we made.
To see the *** Password, uncheck the box “Select and existing template” and then select the “Generate” Radio button – and bam! there is the PSK.
Recently I was asked to look at a local college that is experiencing issues in the evening with wireless users. In this example the complaints from students who live in the dorm are obscure and lacking details. They range from “Wifi goes out” to “Video’s buffer”, and “Its just so slooooow”. So, with this little information known we decided to go over and check out the spectrum to see what was going on.
First I talked with the admins to find out about the building, construction, Bandwidth/networking and how students use the dorm wireless. From our conversation I found that the dorm has dedicated internet of around 400 MBits and monitoring is show it busy but not maxed out. Students are working throughout the day in their dorms, and complaints pretty much only come in at night. Construction is new, but lots of brick – signal should not propagate to far (this is important for later). The building which is 5 floors, stands by itself with little sources of wifi interference outside of internal APs.
We then went on site and did a passive survey with spectrum analysis to check coverage, interference, and if the spectrum was busy. Wifi coverage with was great, lots of APs to cover needed space, maybe too many APs (we will get to that later). When conducting the spectrum analysis —- WHOA! its not busy, but look at the signals that are seen. Below shows an screen shot of the spectrum using Ekahau.
My first thought was that’s a lot of APs! I looked at our layout and we only had about 6 APs in this area, but I see many more than that. So the idea that the building materials (brick) would attenuate the enough that we would not see APs on other floors was incorrect. This gives a lot of credit to on site surveys before installing APs – building materials might be different and react different then we think sometimes. I was seeing APs 2 floors above with usable signal. Another thing to notice that there is plenty of open spectrum in the 5 gig range, why are all the channels being used close to each other and at the beginning of the spectrum? At this client Ruckus wireless is being used and after checking documentation and asking vendor reps, seems like it might be a firmware thing. Also notice that we have a lot of APs on the same channel that can hear each other, this would cause contention on the channel.
This shows the importance of always doing a site survey and checking spectrum to see what AP coverage is.
To help resolve the issues we created a channel plan to statically set channels and spread them throughout the spectrum, also lowering channel width to 20 MHZ since we have so much AP coverage between floors. By doing these two things we were able to decrease channel contention and give our users a better wireless experience.
One additional setting we modified was to block broadcast/multicast from clients. When doing a packet capture on the spectrum we also noticed that around 30 percent of the traffic was just MDNS. We created ACLs to block this traffic.
Recent Comments