WiFi controller solutions have become pretty popular for Enterprises lately. Some of the benefits of why you would want them are.

  • Centralized management over several to many access-points.
  • Unified access policies.
  • Ease of deployment.
  • Rogue AP scanning for PCI/DSS compliance.

Once an enterprise needs more than one or two access-points for providing WiFi services internally the management of them can become an issue. Where is that AP? What IP address range does it have? What is going on with that one?

With more smart services on Smartphones, especially with regards to VoIP, not having to renegotiate crypto stack and keys when you transition from coverage area to coverage area will greatly improve the user experience. Imagine walking down the hall talking on Google Voice, and your call cuts out for 4-5 seconds as the smartphone crosses the threshold from one AP to the next. No one wants to put up with that.

There are two kinds of WiFi access type devices.

The first is an access-point. This is a pure bridge from an ethernet network on the airwaves. It provides no added services, no DHCP, no routing, no NAT. (although I just touched an AP that said it did DHCP, it was buggy with this regard and wouldn’t let me configure it anyway).

The Access Point still negotiates encryption between the client and the access-point with WPA (or WEP) though, and each time the client connects to the next access-point they will go through this negotiation again.

Access Points are not very common. Much more common types of WiFi access device is a router combined with an access-point. This device will do NAT (on its own session table timeouts), maybe supporting things like UPnP or NAT-PMP. Either way, in an enterprise, you are going to end up doing double NAT, and the client won’t be directly reachable by others on different access-point routers, but will be directly reachable on the same access-point.

Going from access-point router to access-point router is an even heavier operation as now the client, as well as having to negotiate encryption again, also has to get a new IP address and will drop all TCP sessions going on (ie. your VoIP call control channel) as it enters the new access-point radio zone.

With a WiFi controller you end up with one central controller that handles all encryption negotiation and handles all networking with only one central policy.

The WiFi LWAPs (light-weight access points) now become much dumber boxes essentially taking all WiFi traffic and tunnelling it back to the WiFi controller on your LAN.

Then the radios in the LWAP basically are just part of one global area. You no longer have different encryption zones moving from radio to radio your client device just uses the closest radio it can get a lock on.

The networking policies also don’t change from radio zone to radio zone. Since everything is tunnelled, it all appears at the controller end-point and that point is where everything starts routing.

I’m most familure with Fortinet’s WAP/WiFi solution, although there are many vendors with this solution. Ie. Cisco, Juniper, Xirrus, MerakiAerohive.

With the Fortinet solution the WiFi Controller software is built into their line of Firewalls (Fortigate) and can be easily enabled making it two clicks to be up and running.

Hooking up a new LWAP is almost turnkey. The current models from Fortinet all use power-over-ethernet (PoE). You plug in your device to your PoE switch, it comes online using DHCP and broadcasts out for the controller. All traffic over the WiFi becomes tunneled. It is not allowed on the main network you plug your LWAPs into.

Inside the Fortigate you will see your new LWAP, authorize it to become part of your network, and it updates itself for the radio parameters you’ve already setup. Adding a new LWAP to the setup can be up and running in less than 30 seconds and provides more coverage immediately.

Since this is integrated into Fortinet’s Firewall solution the new SSID realm you setup becomes a new Interface on your firewall. You can run a DHCP server on that interface, setup policies to allow that realm access to what you need, add NAT translation on your policies, and you’ll be set.

Now, the LWAPs form one area seemlessly serving the client, and the client attaches to the radio with the strongest signal.

Since complying with PCI/DSS requirements for the major credit card clearning houses requires orginizations to not have direct WiFi access bridged on a network that handle credit card data, and to scan for rogue APs that an employee may bring into work with them and compromise network security; some WiFi controller solutions have options to scan for rogue APs.

The PCI/DSS requires companies to specificly scan for rogue APs on some general time frame (it doesn’t actually say how often, but at least quarterly is generally accepted as what it entails).

The Fortigate solution has this sort of scanning built-in, and allows it to see if there is an AP that is also on the wire for the LAN side. Fortigate also can take this to one step higher by sending disassociate messages spoofing as client so that the rogue AP drops the connections to the rogue AP, protecting the network from control beyond what the network administrator knows about.

I’ve been pretty excited to see these sorts of setups deployed, although many non-networking type people don’t understand why double-NAT is bad, or what the deal is with renegotiating crypto and DHCP for each radio zone, they appreciate it much more without understanding the underlying benefits this sort of setup brings.