I was looking at the brochure comparing Sophos Central wireless management versus XG appliance wireless management (https://www.sophos.com/en-us/medialibrary/PDFs/factsheets/sophos-wireless-licensing-guide.pdf), and the row "MU-MIMO" has only a check for Sophos Central's Central Wireless Standard, and not for the XG (nor UTM for that matter). Sophos AP's are advertised as 2x2, 3x3, 4x4, etc, which implies MU-MIMO, so my question is: is the brochure incorrect or is it using the term in a different manner, or are the APs in fact handicapped unless managed by Sophos Central?
Thank you for contacting the Sophos Community.
You would need Sophos Central Wireless if you want to take advantage of MU-MIMO, however, the APXs can still be managed using the XG, only some…
You would need Sophos Central Wireless if you want to take advantage of MU-MIMO, however, the APXs can still be managed using the XG, only some features aren’t available.
Thanks for your clarification!
I'd add that I'm a big Sophos fan, but I have to say that this has really soured me on Sophos APs. MU-MIMO is a feature of an AP and saying something like "3x3" implies a basic, fundamental, low-level feature of an AP. The idea that you don't get 3x3 MU-MIMO if you don't use the appropriate high-level management software is about as nonsensical to me as saying you only get 2.4 GHz bands on the AP unless you use SC Wireless management. It really guts the value of the AP. MU-MIMO isn't a "some feature" kind of thing like most of the others.
I can always manage a firewall from inside via a direct connection, even if there are ISP issues. I feel the same about APs, which are critical for inside connectivity -- in fact APs are more critical for internal connectivity than the firewall or switches when it boils down to it: no AP, no possibility of connectivity for 95% of users.
I went with a Sophos AP for performance and integration with the XG firewall -- even though current Sophos APs are a generation behind WiFi standards. If I was going to have to use cloud management, I could've gotten WiFi 6 from another manufacturer. (Not to mention that one of the most important monitoring capabilities an AP has -- wireless signal strength meters for each client device -- is only available under XG management as far as I can tell, but MU-MIMO is only available with SC Wireless management. So gut performance or gut monitoring, take your pick.
Sorry to go on, and I appreciate your clarification.
I think I get why MU-MIMO is a SCW-only (Sophos Central Wireless) feature: its configuration. It makes sense to me that a firewall isn't optimized to manage the configurations of many devices, and Sophos Central is designed for that.
The issue is that MU-MIMO evidently defaults to OFF, so you need to use SCW to turn it on. But the use cases where MU-MIMO should be off are probably closely aligned with having many APs, in which case the need for SCW is already apparent.
If you would switch the AP firmware to default to MU-MIMO ON, all would be fixed. Small deployments, such as mine, would use the full capabilities of the AP by default. Larger installations where you might want to turn off MU-MIMO -- perhaps even on an AP-by-AP basis -- would naturally be using SCW already and could do it.
You can even make marketing happy: instead of an MU-MIMO line in your table, you can call the ability to turn MU-MIMO off "Advanced radio control" or "Advanced MIMO configuration". That way you have an additional check mark to encourage folks to move to SCW.
This would be the win-win solution. An AP without MU-MIMO is truly handicapped in comparison to competitors and even to consumer-grade equipment. There are negative tradeoffs for a small business to adopt SCW, so allowing them to get the full value of their AP without SCW is proactive.
And after all, MU-MIMO is really a firmware/hardware issue, not a cloud-control issue. It's been turned into a configuration issue when I think it doesn't have to. At least that's my outside guess.
I fully agree. I am totally surprised that I am not able to take advantage of MU-MIMO when managing the APs locally as we do.
MU-MIMO is a basic feature, that is advertised when buying an AP. The fact that it can only be used when managing the APs by Sophos Central is hidden in a PDF file.
BTW: Central management is free. There are not many limitation (if any) by using Central vs locally. So why not moving to Central?
Thanks, I may be forced to use Central for APs.
I moved management of the XSG to Central for two advantages: 1) remote management, and 2) reporting. The XGS doesn't have on-box reporting, so I had to do it through Central. And Sophos recommends against VPN-based remote management and I couldn't get it to work. So two advantages to XGS management in SC, though the biggest advantage -- managing and coordinating multiple firewalls -- doesn't apply in my small-time situation.
In regards to SCW to manage my AP, it's all downsides (except for MU-MIMO): First, it means that if my ISP is down, I can't manage my local AP that is sitting there about 6 feet from me. Which means internal connectivity could be broken, since 95% of internal connectivity is wireless.
Second, I really like the signal strength meters that the XGS provides for AP clients. I can see which frequency each client is on and the signal strength of their transmissions. Invaluable insight for wireless in a crowded environment. (Not mine, but dozens of nearby APs that belong to others.) I don't think SCW offers this, though it does offer other things I don't care about.
Third, I'm wary of the move from VXLAN (XGS management) to VLAN (SCW management). Maybe it doesn't benefit me, but VXLAN has the "X" and VLAN doesn't. But a bit more seriously, the XGS pretty much makes VXLANs invisibly to me when I make SSIDs, but I'm pretty sure that I'll have to make VLANs manually under SCW. I could be wrong on this. At a minimum, I'll have to recreate the work I've already done to set up three SSIDs under XGS management, ranging from setup to setting passwords. It will involve a lot longer downtime than it might seem and it can't be pre-configured, it will have to be done with the AP off-the-air while I'm getting it up and recreated in SCW.
Regardless, it's pretty crazy that a low-level hardware feature that doubles or triples wireless network speeds requires cloud-based management to use. It should be on by default -- I can't think of any reason you'd want it to be off. If it defaults to ON, there's no reason to use SCW unless you have multiple APs, APs across multiple sites, multiple firewalls, etc, which would benefit directly from cloud management.
Is this a real "issue", if you internet ISP is down, you cannot "change" the local SSID. I mean, thinking about the use cases here: What do you want to change in case of your internet outage in the first place? From my point of view, i am not change "that much on my Access points" in the first place. And coming together: ISP/Internet is down + i need to change something seems to be a quite unlikely occurrence.
You should see the second point of yours.
VXLAN (Separate Zone) vs VLAN is likely to be a issue in installations, where you cannot have a managed switch in the first place.
Separate zone was build for this scenario: You do not have a switch, which is capable of doing VLAN. But most likely (nowadays) this is possible and should be used to make the process of Routing/Switching more transparent. VXLAN has this issue, it is most likely completely "transparent", which means everything inbetween has no interaction (and can cause issues, see IPsec etc.).
In the end, why do a wireless management in on a firewall in the first place? Its like Email protection. From my point of view, this component can be used on a cloud solution (which is a more capable product in the first place). Its like: Cloud vs on premise: Advantages vs disadvantages and most cloud products have more benefits to it.
Thanks for the insights.
I'm not sure what you're saying about my second point -- signal strength meters. Does CSW support that? It's something I consult on a regular basis as devices move around. It doesn't measure the signal strength that the devices see from the AP, so it's only part of the equation, but my assumption is that the AP is more powerful than most portable devices so the limiting factor is their signal strength at the AP.
I have no switches, managed or otherwise. With XG management of the Sophos AP, none are needed.
Just to be clear, I have one AP, three SSIDs (not one SSID with multiple APs). You mention Zones and in my particular case, two of the SSIDs are guest-like and exist in one (less-trusted, less-monitored, devices isolated) Zone. The other SSID is higher-trust and is bridged to another port on which a NAS resides, with the resulting Zone having more features enabled (TLS inspection, etc, but devices not isolated). This is sounding complex to implement from CSW, but it was trivial to implement on appliance.
And its sounding like it would take a start-from-scratch approach both in CSW and in the firewall. Maybe I'm just overblowing this part, but it certainly makes me feel like there's a much higher risk of a mostly-working configuration and an unexpectedly long down-time to convert from XG-managed to SCW-managed.
I agree completely that managing many switches, APs, or routers is a natural fit for a cloud solution and not a firewall. Especially when multiple sites are involved. Total win there. But MU-MIMO isn't something that needs the cloud in order to be on by default. It's a low-level hardware/firmware feature that has to do with radio frequency management, not something that should require or would benefit from the cloud.
I can also agree that the odds of me having to do something to an AP at the same time I'm also experiencing ISP or other internet connectivity issues is unlikely. But at the same time, I hope that you can agree that a small deployment where all equipment is basically in sight of everything else feels weird requiring internet connectivity to maintain. Especially for a feature that is hyper-local like MU-MIMO, and for which I can't imagine a situation where you'd actually want it off.