no more wireless controller, apart from a Fortigate

[LouiKirs]

I'm perplexed that the controller function will in the future only be via a Fortigate (based on recent updates communicated by Fortinet).
I'm not a fan of buying stuff and not using the functionality.

I have two points:
- Would the use case for controller-only deployments (i.e. no need for the Fortigate's firewall & SD-WAN function) be such a small part of the WiFi architectures that it makes sense to not have a dedicated controller in the architecture (whatever the technical reason behind this)?
- Because a Fortigate scales based on throughput and horsepower needed to run the perimeter firewall functions, getting a controller for a large deployment means buying a monster firewall and not using any of the intended functions, and at a serious price point.

Does this mean that WiFi is always a sub-set of a SD-LAN and not really a lead product?

Interested in your views to help me understand.

[ChriHins]

Hello Louis,
   There are several aspects to your post and I want to ensure I unpack and answer all of them.

   Yes we are moving away from the FortiWLC dedicated wireless controller platform.  This was primarily because the FortiGate controller functionality had fully matured and the Virtual Cell architecture (which the FortiWLC was known for) was less and less important in modern Wi-Fi environments.  (More on that can be found in this blog from a few years ago.)

  It's Fortinet's belief that every network should be properly secured (which usually means a firewall either onsite or in the cloud), and we believe that the FortiGate is the best firewall available to the market.  So we see this as giving customers more for their money (they get a WLAN controller as part of their firewall purchase).   Or as one of my coworkers likes to put it, you're buying a WLAN controller, and getting an industry leading Next Generation Firewall (NGFW) for free.  Keep in mind that when buying a WLAN controller, you'd be buying the appliance, plus all the licenses to make it run.  With the FortiGate, you only need to buy the appliance (or VM).  In your second example (the large deployment one) I'd be curious to understand how network security was being handled in such a site?  Presumably a large deployment such as you describe has a network security solution of some form, and what Fortinet offers is the consolidation of two appliances / solutions into a single purchase, saving money and management hassle.

If using a FortiGate (whether appliance or VM) is completely off the table, there's still our cloud based management platform FortiLAN Cloud which gives you the ability to manage our access points and ethernet switches independent of the presence of a Fortinet NGFW.  This is an option we have had several large customers move to.  An added bit of flexibility with our architecture here is that the same APs that work for the cloud also work with the FortiGate, so our customers can choose to use FortiLAN Cloud today, and if years later they do choose Fortinet as their firewall supplier, there's no rip and replace necessary to move those LAN & WLAN devices over to be FortiGate managed.  In fact we have had customers do exactly that when budget cycles for the LAN vs. the firewalls were several years apart.

Finally you ask if Wi-Fi is viewed as a lead product for us, and the answer is yes, definitely.  In fact, the move away from the old dedicated controller platform is because we intended to double down on the importance of Wi-Fi in our other lead product, the NGFW.  By focusing our efforts primarily on Security Fabric integration with our primary product line, this brought Wi-Fi more into the fold as a primary technology for the company.  We will always be a security company, and as we looked at what it meant to have security at the core of every network, the FortiWLC architecture was not a good match for that vision.

I hope this helps to answer your concerns, and please let me know if you have any further questions.

[LouiKirs]

Thank you for the comprehensive answer.

I'm going to respond as per your paragraphs to help keep things sane

Agree that this change was due to product and technology lifecycle

on the next two paragraphs I also agree that there is a lot of value in the Fortigate package, which includes the WiFi controller.  But consider a site that has a WAN connection (SD-WAN) that can quite happily run on a dual 80F or even dual 60's as WAN edge, including the perimeter security functions.  but the site WiFi AP count is close to 100 units.  in this case, using the AP count as determining factor for the site connectivity means using a more expensive edge device (x2!) to cater for the WiFi requirement whereas the user count and other network demands (number of switches, etc.) means a much lower (cheaper) device can be used.  if I separate the WAN from the WiFi, I end up using a 100F only as WiFi controller and have no redundancy - adding 2 means even more cost for no added functionality).  Combining the WAN and WiFi is a difficult scenario due to insane availability on the WAN and a really tight change control regime that means keeping things separate makes life a lot easier operationally.
so I end up with an environment where a WAN controller is on an expensive firewall due to AP count requirements and the WAN edge can happily chug along on much lower end devices due to the perimeter requirements.
maybe a very special use case then?
maybe offload the WiFi management to a central WAN core and share that core controller device amongst sites / customers?  might add value in being shared ...

On WiFi as lead - good to be reminded of that and also of the vision, which I totally buy in to.

Trust the above helps to understand the reason for my initial question.

[ChriHins]

Hi Louis,
   Thanks for the example details, it's an interesting case, so let's build it out.  I think to make this site work, we'd need to assume that it's large, but the network is only sparsely used.  I say this because it's got 100 APs, but the traffic is light enough that a 60F can handle securing all traffic in the site (I'm not just considering north-south traffic, but also securing traffic within the site).  So maybe it's a large warehouse with mostly beep & scan traffic.  [If there was a steady amount of larger traffic, you'd likely want a larger NGFW anyway as 100 APs worth of traffic is a reasonable amount to secure.]  Not an unrealistic situation, but probably not the most common either.

So let's say it's a warehouse and (as you say) a 60F or 80F is more than enough to handle the onsite traffic & the WAN link.  In this case it would make sense to look at using FortiLAN Cloud, that could manage all the APs and switching (gonna need a lot of PoE switches to take the few 60F ports and cascade that out to 100 APs) without needing to overprovision the NGFW/SD-WAN appliance as you point out.  I'd say this is a customer decision point on where they see their business going and how they see themselves scaling (if at all) over time.  If they think traffic will be increasing, then going with the larger appliance now may be the better way to go.  If they don't see bandwidth (whether internal or across the WAN) being an issue any time soon, then FortiLAN Cloud seems the better choice.

On the whole I'd probably lean FortiLAN Cloud here, particularly given that it's not a lock in architecture.  If unexpected growth does happen, they can always consolidate back to larger FortiGates when the time comes.

[LouiKirs]

Hi, Chris

You are correct in the application as beep&scan - large area to cover but a relatively small workforce in operation.  and quite a few switches.

So, the only question relating to using FortiLAN Cloud would be a WAN architecture that enables high availability (access and internet) and a suitable application availability rom Fortinet.

So this actually becomes a best of both worlds, with the gates on the perimeter focusing on perimeter stuff and FortiLAN Cloud focusing on the LAN stuff, each scaling independently.

time for a pilot project I would say ...