Today had a strange issue with a Zondirector 3k and thought I would share in case anyone else has the issue. For some reason all of a sudden the web interface started showing this error:
Request Error
Error logged at the server
Enable EjsErrors to see errors in the browser.
SSH, ping, and AP functionality all still worked great. First we tried to reboot the ZD, but this has no effect. Next we tried to redo the cert – and this was the fix.
A client recently had an issue where a security audit found ciphers supported within HTTPS that are insecure. These ciphers were TLS 1.0 and TLS 1.2. The audit found these issues on the web interface of the Smartzone, nothing to do with EAP or WiFi authentication. . After trying quite a few things I decided to open a ticket with Ruckus support. They instructed me to run the following commands on the SmartZone to disable it:
vszh-50#debug
vszh-50(debug)#
vszh-50(debug)# no tlsv1
This seemed to fix the issue. The web service (Tomcat) restarts and takes about 5 minutes before you can log back into the SMZ again.
This is a design I need a few weeks ago to help with a redundancy issue. Currently we have a client that occupies two buildings separated by about 500 hundred feet. Soon they will start construction to add a structure right in the middle , connecting the two buildings. But guess what runs right in the middle of this area? The fiber connecting the two buildings. We are thinking that the construction will most certainly cut the fiber causing an outage, whether planned or not.
We decided to have a backup wireless bridge link to help with redundancy. Ruckus’s P300 AC bridges works great, and that is what we decided to do .
Currently the link between the buildings is a Layer2 Trunk, and we are routing over Vlan 254 which traverses the trunk. OSPF is used to advertise each building’s local subnets, and redistribute the default route.
The goal is that routing/layer 2 will only come active on the wireless bridge in case of a failure in the Fiber connections. So Spanning-tree will block all vlans other than the native 200 – going through the bridge. If there is a failure, those vlans will come online over the bridge, routing will come up, and all should work great.
The switching/routing that is used is a Nexus 9500 and 3850 stack.
To accomplish the above, we enable OSPF on vlan 254, and make sure all routing is correct – including redistribution. Vlan 254 our routing vlan is allowed along with a few other vlans – At some point this will be fixed and we will only route over this link, but for now we have to stretch (I know, not the best practice). Building 1 is currently the STP root for all vlans stretching over layer 2 link. The Spanning-tree path cost is increased on links connecting to the bridge, and special commands are enabled on the wireless bridge to disable the Ruckus loop detection mechanism. This is very important because it will stop STP from flowing by default. Follow this link to help with that:
After the bridge was setup, path cost modified, and Cisco port configs set correctly – it is time to test. First we needed to make sure STP was indeed blocking the vlans that were needed. Yes! STP is blocking the redundant path.
Testing/Results
We tested fail over in two ways. 1 – just shutting down fiber links in CLI, and 2- physically unplugging the links. During fail over we saw that 2 pings were lost and then they were back up. I actually thought that OSPF drop, and then re-converge, but that did not happen. Instead, since the Hello-Dead timers were never reached, OSPF never dropped – fail over time was much better than I expected. The only way I could really tell we had failed over was a small increase in latency, and of course we were limited to around 300 Mbits.
Some notes on this – Make 100% sure that the Ruckus loop detection is disabled before even starting actual bridge configuration. Also create some kind of alerts VIA Prtg/Solarwinds/Cacti to send an alert if links go down, or their is a big increase in bandwidth on wireless bridges.
I wanted to create a backup link for a network using a P300 bridge. The current network has two 10 gig links going between two buildings, but construction is set to start soon, that could cut the fiber stretching between. One option was to use the P300 bridges to create a backup link between the two building, which would become active in case of a failure in the fiber links.
We are currently stretching maybe 12 vlans between the buildings. The goal was to have all data go over the 2×10 gig links, and Spanning-tree block the other vlans from using the Bridge. I increased the STP port cost on each side and brought up the bridges – and both fiber links and bridge were forwarding, causing a loop. It took a bit to understand, but according to Ruckus their Gateway bridge detection mechanism basically stops STP and LACP from forwarding. I found the below help doc from Ruckus which gave the command to disable this feature.
This is an amazing method for getting users in their correct groups in Fortigates. This way we can apply different security profiles to individual groups, all through one 802.1x login. This example is using Ruckus wireless , but will work exactly the same for any wifi vendor..
This method works by using 802.1x WPA2/AES logins on the Ruckus , and passing the users info over to the Fortigate by Radius accounting. Then on the Fortigate we are using RSSO (Radius single sign on) groups to collect the username/group that is sent to the Ruckus by the Windows NPS server. Lots of moving parts here, but it is really simple. I have had problems finding good documentation about Fortigate’s RSSO profiles – but they work great.
The goal of this project/entry is to have the Fortigate know the Username, IP and group (if assigned) of the user who just authenticated to the wireless network. Once you know these things you can apply different UTM policies to users VIA RSSO groups in the Fortigate. There are many good scenarios and uses for this – one example that I have is for a school network. I set this up recently for a school that has students and faculty authenticate through the same Ruckus controller, but to different 802.1x WLANs (SSIDs: Student and Faculty). The fortigate can then apply correct policies to each user (student or faculty) and therefore lock down student web surfing much more than a faculty member. You might be saying – you could just use captive portal on the fortigate,with LDAP groups. I would say yes, but that is another step users have to take, and its called “Single Sign on” for a reason.
So what is needed to make all this happen: Ruckus wireless using 802.1x, NPS (or any radius server) , Fortigate – that’s it.
I am going to assume that we already have Ruckus using 802.1x and NPS with no problems.
I had trouble at first setting this up, because I thought that that the NPS server should send the radius accounting info to the Fortigate, I was wrong. The controller is the Authenticator – therefore the device that knows about the authentication, and needs to pass on the info to the Fortigate. The Authenticator (Controller) needs to send the radius accounting info to the Fortigate.
That means you have a AAA server setup on the controller for 802.1x authentication, and a AAA radius accounting server pointing to the Fortigate.
Setup Radius accounting between Ruckus and Fortigate
First we need to create the connection between Ruckus and Fortigate via radius accounting.
On the Ruckus system, go to Configure – AAA servers – create a new server. Then click the box that says “Radius accounting” Fill in the IP of your Fortigate, and create a PSK between the two.
Next on our Fortigate we need to create a RSSO profile for the Ruckus system.
Feel free to name this Ruckus or whatever. The PSK has to match what you created on the Ruckus system. By default the RSSO profile uses the Class variable to match the users. You can change what to match, for example you could match by NAS-Port, User-Name, Class, etc.
So, if we go into CLI we can modify many of these settings. Below are the settings I have used
config user radius
edit “Zonedirector”
set rsso enable
set rsso-secret ENC eoTXOqectoW0sjb5lLVW/7rr3BB0DocxlKeW64yfoIq7NTblyMc1TT9/V2M8m2LJmotwNrDYS+hOBSWV68wWULjuT88tOZHli7Nqqe8k5hoK4iHmLuG6x9R7apR9b+JU6O48mY8jiUaf48pY8wamagNdOALtrew6k+yWFzfd7gzo+qgag2sOI+Q46GnI1ybGPo6YQQ== set rsso-endpoint-attribute User-Name
next
end
Next we need to modify NPS to send the values that we will match on the Fortigate. In this example I am matching I am saying that if any Domain users authenticate through the ZD, then send the IP/Username/”Tag” to the Fortigate so it knows who to apply the correct firewall policy to. My “Tag” I am sending in is the Class Variable of “Domain Users”.. Something to note is this is not the given AD group, but a variable I am assigning that just references the group. I could say “Social media” if I wanted, then match on that.
So lets modify the Microsoft NPS policies to reflect what we need.
Remember, we are going from the assumption that 802.1x is up and working, and NPS is great. So, how do we match a variable from NPS on the fortigate? We could really use a ton of different variables. Lets use the class variable. To assign the class variable we will modify the the Network Policy in NPS that we want to apply a to a certain criteria.
I will modify my “Connections to Wireless VIA AD Authentication” Policy. Then once, you edit the policy and go to “Settings” tab, there will be a few attributes already listed . You may have some already or not. We will add the “Class” variable, and then assign it to what ever value we want to match in the firewall group. In this case I am setting my value to “Domain Users”.
So from the settings tab, lets click “Add” under the Radius Attributes standard section.
Select “Class” from the list of attributes that comes up, it will then ask you to enter a string that you want to set. This is the Keyword you will use to match the user to group in the Firewall. Just like use a FSSO group and matching the domain group. Some examples might be students vs teachers, or Domain users.
Press OK, and now we have the variable added, you can confirm as seen below:
Great, now we have the hard part done. Now, have some users log in to wireless, and see if you get correct RSSO users found in the firewall. you can check this my navigating in the firewall to User&Device – Monitor – Firewall
Awesome, it found my username, and my IP, but my group is blank, how can you apply a policy to user if they have no group? The answer – is just the same as the FSSO. If you do not have a firewall policy that references the Radius group that you created then no group, no filtering, nothing. So you need to create a new firewall policy and select the RSSO group you created as the source group. In my example the group is called Radius Domain Users.
To show a policy example check out below: My domain FSSO is above my RSSO policy.
Now that that is created and enabled, lets check the user monitoring – BAM! there it is, my group included.
Using RSSO and 802.1x is awesome, it allows you to kinda use a single pane of glass aspect and have Firewall, and Wireless be able to know who the user is just my them logging into the wireless network. Also, using 802.1x for wireless authentication and Key management is very secure. Having users known that are on wireless no matter what device can really be beneficial in reporting, either through Forticloud of FAZ.
Ruckus brought in the Guest Self Service portal in firmware 9.10.0.0 build 218 – so if you are looking to configure it please install this update first (Check release notes for proper upgrade path). After we are on build 218, lets get configuring.
So the Ruckus Guest self service portal is Ruckus’s first step in creating an “on boarding” process. It allows administrators to make sure that there is at least some kind of authentication on their guest WLANs. The portal gives guest users the ability to create their own guest pass, and the admin can set many options of the guest pass such as expiration, amount of devices that can be registered with this pass, and how the pass is given to the user – for example you can send it through text, email, just show it to them on the screen, or a combination of all. So this feature is great, and helps admins authenticate guest users with very minimal intervention.
So how do we configure this?
First we need to create a new Guest access policy. This is located under Configure – Guest Access. Create a new portal.
Lets now configure our portal page. A few options that are very important are:
Enable Zero IT Registration from the Guest Portal – Use this if you are also planning to register devices. I was confused by this at first. As you will see you have the option to use guest pass, or register a device. When you register a device you are just using Zero IT as normal to get on the secured network.
Authentication – Use guest pass for this. Since thats the goal.
Next you have a lot of options such as Terms of service and time out.
The main box you have to check is the “Guestpass Self-Service” box , you will then get a lot of options to do with that process and how to get the guest pass to the user. A few things to note, if you want to txt them, or send the pass through email you will need to configure a mail server and/or SMS server in the settings of the ZD.
If you notice there is a small “Restricted Subnet access” – Its kind of hidden in my opinion. This is very important. If this is used for guest access more than likely you will want to make sure that guests cannot access internal hosts. This is where that is done. This or the Layer 3 access list. Remember Ruckus does the filtering on the AP, so having to have a ACL on the router is not needed. Below if the full Guest access config.
That is about it for the Guest portal. Now we need to create a WLAN and use it for our guest access.
So, lets create a WLAN at configure – WLAN- create a new one.
Things to note – Select “Guest Access” Then select your Guest access Service portal you created.
Great!! All done, so what happens when you connect?
First you will be presented with the on boarding portal that asks if you would like to use Guest Access, or Register a device (Zero-IT).
Select “Guest Access”
On the next screen it will ask you for your Guest pass, but you don’t have one yet. Select the button to create a new pass. Note that you have the option to Query the status. This is a feature if you want to approve guests of getting a Guest pass before they do.
On the next screen you will be asked to fill out your information.
And here you go! you have your guest pass, which is valid for the length of time that you configured in the policy. Copy and keep this key. The ZD will automatically copy the key into the next page for you. Select to go to Guest Access portal.
You can see the the ZD copied the key for you. Just Press submit.
And there we go!! We are online. Ruckus does it again with making getting on Wifi easier. Now we have a built in On boarding portal.
You can view the Guest Pass and its config under Monitor-Guest pass to find out who the GP was assigned to, when it expires, and you can delete them from here as well.
Ruckus has done a great job giving us a simple but effective way to on board users for Guest and/or internal use.
Ruckus has finally built in the ability to use LLDP to find Access points. I was so excited when I found this out, I installed the newest firmware and was ready to be blown away – and alas.. no LLDP. So, what was wrong? LLDP is not enabled by default! You have to go into the AP group via CLI and enable LLDP. No biggie.
Hello all, I recently was given a strange task. An office needs to have everyone in there office on different vlans. The reason for this is that each user is developing software and they need to test VIA wireless to other wireless devices. Lots and Lots of broadcast, as well as different subnets. So, how can we separate each of these users wirelessly and give each of them their own “play space”? You can accomplish this a couple ways: We can have 100 different WLANs, each with their own Vlans, or use 1 SSID and use Dynamic Vlans to separate them out.
The tools I will be using are – Ruckus Wireless Zondirector, and APs, Microsoft NPS, and Wireshark to take a better look at what is happening at the packet level.
So first lets setup everything. We need to use 802.1x authentication for WLAN Access. I will not walk through all the steps here but definitely do another blog entry on setting that up. So lets assume as of now we have 802.1x working great for authentication.
Our next step is that we need to create new Security Groups in AD and add our users to them. I added groups that reflected the Vlan name. For example WIFI-VLan-150 and then added my user I want to get VLAN 150 to.
Next lets create our Radius Policies.
Create a new Network Policy- match the Group, add your Encryption and other settings. See below:
Then add your Constraints that you would like:
Next the magic happens – we have to add in our Radius attributes . These are Standard radius attributes. We will add 4 802.1x attributes.
Attributes to add:
1. Tunnel-Assignment-ID – String – Vlan ID.
2. Tunnel-Type – Select Virtual Lans (VLANS)
3. Tunnel-Medium-Type – Value – 802 – Commonly used for 802.1x
4. Tunnel-Pvt-Group-ID – Value – String – Vlan ID. Note – I did not add this at first, this attribute is what fixed my issue, and successfully pushed the Vlan ID to my client.
Here is a screenshot of all the attributes:
Make sure this policy is above your default policies. The next screen shot shows my order of policies. Notice I have one for 666 vlan, and 150. Then there is a domain computer, then a catch all for domain users.
That’s it for Radius, now we need to create the WLAN for in Ruckus for our Dynamic Vlans. Remember, we are assuming everything works great with Radius authentication from the get go.
The main thing when creating the WLAN in Ruckus is to use 802.1x for authentication, and then under “Advanced” check the “Dynamic Vlan” box. You will notice I am using “SRV-dir03” For authentication (My Radius Server). Apply this and we should be golden.
To check and make sure you are on the correct vlan/wlan you can always check your ip address or look into Ruckus and see what your info is. You Notice mine –
Recently I and others have had an issue when using interface based VPNs on Fortigate, and remote Ruckus APs are on the other side of the VPN. For some reason these APs cannot register with the ZD – sometimes they never even show up. I can log into the remote APs, SSH, Web, Ping everything works they will just not register with the ZD.
When I see this the most the client has just updated to Fortinet 5.2 firmware, and is using Interface based VPNs instead of policy based.
Now back to the main goal of the entry – If you are using a interface based VPN with Fortinet specifically you might see your APs come up for a while, then drop. Another symptom I have seen is that you have your DHCP options, and DNS record set for the Zonedirector but the APs never show up. The underlying issue is that the interface based VPN will drop sometimes – the Fortigate may not even report the drop. During this time the the Logical VPN interface is no longer attached to the Fortigate, that means the route you set to push traffic over it to the remote subnet no longer exists. So a UDP session is opened to the internet – since there is no other place to send the traffic to. Once that happens the UDP stays active – Even though it should timeout.
So to fix the issue, Add a service for “Ruckus services” and add UDP and TCP ports 12223, and UDP and TCP port 12222. Then create a policy in the firewall to block traffic going to the WAN on those ports. This will make sure that remote sessions are never created to the internet interface. So if the tunnel drops you will not have to worry about this. You could also just create an address object for your remote subnet and create a policy blocking any traffic matching that object going to the WAN interface.
Here is the policy to block the traffic from leaving the WAN interface
Note – Make sure this policy is above any traffic that would be go from internal – to VPN.
After the policy is created to blog those ports – lets clear the sessions in the firewall. We can do this using the CLI command in the Fortigate:
Dia system session clear
So how did we figure this out? If you do a packet capture on the Fortigate matching the ZD or AP ip addresses, you will see registration attempts trying to go through the WAN interface, even though the VPN is up. Since UDP is connectionless, it never expects a response on the session, so it stays up. If you see the session going through your WAN interface, and your VPN is up, just kill that session. You will see your AP come up very quickly, but the same issue will happen if you don’t make sure the session is never created.
This has fixed the issue for a few clients having this problem.
I was having some trouble getting SNMPv3 up and working on PRTG and Solarwinds. It was a straight forward config but something wasn’t working. The following steps will show how to configure SNMPv3 on Ruckus ZD, and pull info from it on PRTG. Why SNMPv3? it offers a lot of more features such as encryption and user authentication. Definition:
SNMP Version 3 (SNMPv3) adds security and remote configuration capabilities to the previous versions. The SNMPv3 architecture introduces the User-based Security Model (USM) for message security and the View-based Access Control Model (VACM) for access control. The architecture supports the concurrent use of different security, access control, and message processing models. More specifically: Security
First we will configure the ZD
Enable the SNMPv3 agent, and create your user/pass/hash/encryption.
For some reason you have to have a R/W user in the ZD. This does not seem to be a requirement of v3.
Next lets configure PRTG, and find out where I made my mistake.
So everything is pretty straight forward, but I was putting admin in for my context name as well. This was breaking the connection.
The context name is a collection of management information accessible by an SNMP entity. A context is identified by the snmpEngineID value of the entity hosting the management information (also called a contextEngineID) and a context name that identifies the specific context (also called a contextName).
Recent Comments