Managed WiFi in the MDU

We operate in an apartment building with over 50 units we provide service to. Initially, we thought the best plan of action was to put an Ethernet network jack in every unit, cable that back to the switch on each floor and let the resident choose their own router. We set up DHCP Option 82 to manage IPs and billing. On our end, this was dead simple. On the resident end, it was less than desirable.

What we ended up with was an unusually large support call volume for “slow Internet”. When a network jack was tested via Ethernet, speeds were over 900 Mbps upload and download. But, on WiFi, most residents were seeing under 10 Mbps. The problem? massive WiFi interference from all those customer routers.

WiFi scan from the courtyard

WiFi scan from the courtyard

It was impossible to even read individual SSIDs in our WiFi scan. But, look at all that dead 5 GHz space in the DFS channels! An opportunity to fix this problem was waiting…

We decided the solution was to go with managed WiFi so we could control the airwaves and mitigate this problem. Now, we had to decide which way to go. We looked at a handful of options:

  • Mikrotik hAP AC in every unit with a separate SSID for each unit. We control the channels and power.

  • UniFi solution with an AP in each unit and same SSID for the building. No way for a resident to plug in any devices like an X Box and single password for everyone (ie: flat network).

  • Same as above but with dedicated SSID to each unit on separate VLAN.

  • Real managed solution with Cisco or Ruckus using a single SSID but dPSK security (more on that below).

As we put costs / benefits on paper, Ruckus began to emerge as the leading solution. The reason is two fold.

  1. Virtual Zone Controller can be run on existing Proxmox hardware for less cost

  2. 10,000’s of grey market APs available for dollars an AP

The sheer volume of Ruckus grey market equipment made them a popular choice. We could buy the 60 APs we needed for $20 each and get a modern 802.11 AC AP with 4 LAN ports allowing the resident to still plug in their own devices if they wanted (using the H500).

We took the plunge into managed WiFi and set up the building like this:

  • Mikrotik CCR 1009 router serving over 50 VLANs (one for each unit). Each VLAN has a /24 of private IP space (from the 172.16.x.x/16 block). Each VLAN was SRC-NATd to a separate public IP. This allows us to track take down notices and do our shaping with our Preseem boxes.

  • Mikrotik 24 port POE switch on each floor. Each port powers an AP and sends all VLANs tagged to that AP as well an untagged management VLAN.

  • The untagged management VLAN is using DHCP Option 43 to insert the address of the Ruckus virtual smart zone so a new AP knows how to get to the controller which is off site (see below for example).

  • Controller has a single SSID for the building and then over 50 dPSK passwords. Each unit has a dedicated secure password that when used, puts devices on that unit’s VLAN / subnet. This allows a device to roam to any AP in the entire building and still be on their own private LAN.

  • Each AP has 4 LAN ports and they are all set to be access ports for the VLAN for that unit. This way, you can plug in an X Box and be on the same subnet as your WiFi devices.

  • Sticker on each AP gives the resident the building SSID, their unique password and our support number.

  • APs set up to only use 20 MHz channels in the DFS range. 2.4 GHz radios are shut off in many of the units to cut down on noise but still allow coverage.

Now, we can take a factory reset (or brand new) AP out of the box, plug it into the Ethernet jack in each unit and that AP will power up, get the controller information from Option 43, get correct firmware from the controller and receive the configuration for that building all automatically, We only need to log into the controller and set the LAN port access VLANs to untag the correct unit’s VLAN. But that is a one time setting.

This now allows us full control of the RF environment and we can see into the network to troubleshoot resident connections. The residents have over 50 APs their devices can connect to all with the same password dedicated to them. VLANs can not see other VLANs for security. Each VLAN has its own public IP address and we can traffic shape each public IP separately using our Preseem boxes.

For setting up a Mikrotik with DHSP Option 43:

  • Go to this site to get hex value of controller IP: https://shimi.net/services/opt43/

  • E.g. 10.254.254.101 option 43 hex 060e31302e3235342e3235342e313031

  • On Mikrotik go to DHCP Server – Options – add

  • Need to add 0x in front of hex value to let Mikrotik know it is hex

  • Name ‘Ruckus-controller’, code 43, value 0x060e31302e3235342e3235342e313031

  • Go to DHCP Server Network and assign the option just created

For setting up Ruckus virtual Smart Zone (vSZ) on Proxmox:

There are a couple things to note on this. For those familiar with Proxmox, you probably have this workflow down. We were not there yet and ended up re-doing it a couple times.

One big catch… If you are using end of life APs, like we are (the H500’s), you need to figure out what the latest version works for them (in our case, 3.6.2) and build the vSZ with that version first. You can upgrade but you can not downgrade vSZ versions.

Once we build the vSZ with 3.6.2, you can then have up to three consecutive versions of the software on the vSZ. For us, those three versions would be (in order):

  • 3.6.2

  • 5.0.0

  • 5.1

No one wants to run a 5.0.0 of anything so we skipped 5.0.0 and have 3.6.2 and 5.1 running on the vSZ. This means, when we create a “zone” on there for APs (ie: a building), we can decide which version the zone gets. If we plan on using old EOL hardware, we choose 3.6.2. If it is new hardware that is still active, we choose 5.1. We can’t go any further with versions on this hardware if we want to continue to support the H500s we have deployed.

Here is a step by step document for getting the vSZ up and running on Proxmox.