Wi-Fi tunnel concentrators are a new wrinkle in wireless networking, driven by cloud vendors realizing there are, in fact, advantages to controller-based architectures. Fortunately for Fortinet customers, our Wi-Fi architecture already combines the best cloud and controller architectures while being most straightforward and, unsurprisingly, most secure.
When it comes to Wi-Fi traffic, I’m pretty sure the Bard said, “To tunnel or not to tunnel, that is the question.” Or was that General Chang? Regardless, there are two basic options to consider with Wi-Fi: 1) tunnel traffic into a controller or other traffic concentrator or 2) don’t tunnel and have network traffic breakout locally and be handled in the same way as direct/traditional traffic. Up to date Enterprise Wi-Fi systems, including Fortinet Wi-Fi, can be expected to support hybrid options, tunneling some SSIDs while others go directly onto to the local network.
A quick look at the evolution of these options will put things in context. NOT tunneling, or local breakout, is the most basic idea and initially the only option. Logically, an AP is a switch. It is a layer two device with a virtual wireless port for every connected client and Ethernet ports to get to the rest of the network. That’s the obvious way to build an AP – a switch with virtual wireless and physical wired ports. The first APs were subsequently called “fat APs" because they included all necessary functions in the AP.
As they were rolled out, fat APs demonstrated three problems. 1) they needed central management. Ethernet switches also needed central management, but even a handful of APs needed a central place to configure SSIDs. 2) VLANs and different classes of users tended to force more complex architectures on the Ethernet backbone, with a need for trunks everywhere. 3) Initially, with WEP, Wi-Fi was insecure and needed to be isolated from the rest of the network. Even as security improved with WPA enterprise, the reputation for insecurity remained, and as Wi-Fi networking grew more complex, a central policy enforcement point became desirable.
So, we got tunneling to Wi-Fi controllers using “thin” APs, a thin AP being one that split its functionality with another device, a controller. The AP itself had the necessary radio and Ethernet port(s). Still, all traffic was tunneled to the controller and only then ‘released’ to the network with any VLAN tags or similar alterations, and any replies went to the controller before being tunneled to the AP and sent to a client (end-user). This is an easy overlay for any existing architecture, with no need to change anything on the Ethernet switches. AP control is easily treated differently from user traffic, and user traffic is easily isolated from the network. Any security policies can be applied at the controller as the single break-out point.
Then we got cloud-managed APs. Controller-managed APs sometimes had scalability issues – the controllers became the bottlenecks, for a while, AP speeds were outstripping switch speeds, etc. There were a few predecessors, but cloud APs are centrally managed fat APs, and cloud management enables immense scalability
However, cloud APs brings us back to the problems of how and where to apply security and how to keep the underlying Ethernet network simple. No one wants all their Wi-Fi traffic tunneled through the WAN link. Everyone wants to maximize security or target it where it matters (less so on guest networks).
The final tweak is Wi-Fi tunnel concentrators. There are not a lot of Wi-Fi greenfield deployments these days. Most Wi-Fi deployments are refreshes of existing networks. Even when a new network gets deployed in a new building, it may still have to follow an existing architecture dictated by corporate HQ, the school district, or some similar entity. Many networks continue to prefer the overlay model for the obvious reasons – security policy enforcement concentration and simplified Ethernet switching.
Wi-Fi tunnel concentrators, sometimes called something along the lines of ‘data-plane concentrators,’ partially add the tunneled controller/thin AP model back into the cloud model. A VM or appliance is installed in the network. AP traffic is directed to it, exactly like it would be for a controller-type deployment – except it takes some additional configuration, and management remains elsewhere. Traffic can then be broken out at the concentrator, usually directly into a firewall/router.
Fortinet makes this ALL much simpler. Every FortiGate includes a WLAN and Switch Controller, and the FortiGate is cloud manageable for unlimited scalability. No concentrator is needed because every site has a controller to perform that function and more, but the cloud management of FortiGates provides all the advantages of the cloud.
At Fortinet, we don’t treat the network as a collection of parts but as a whole, unified fabric. The network’s purpose is to connect devices, especially to the Internet. The Internet is the critical network edge, and that edge needs an NGFW such as a FortiGate in ALL cases. Every FortiGate includes a WLAN and Switch Controller. Whether you think of it as a data-plane/tunnel concentrator or a complete WLAN controller (after all, it is both), it is there, and there is no charge for it – not even AP licenses. All the advantages of a Wi-Fi controller without having to deploy one. No need to unbox it or find a server to run a VM on. If there is a FortiGate deployed, a Wi-Fi (and Switch) controller is already up and running and on the network. You don’t even need to find another IP address.
As to cloud scalability and usability, FortiGate Cloud and FortiManager Cloud have all the scalability necessary. More importantly, it can unify the ENTIRE network into a single management platform – Security Driven Networking simplifies networking.
