We're a Sophos partner trying to rollout XGS firewalls with Sophos APX broadcasters but hit a major issue where our orders for broadcasters are grinding to a halt. the APX 530 and APX 740 are out of stock according to Sophos with NO ETA.
Nice one Sophos, you make XGS 18.5 no longer support older broadcasters, forcing customers to upgrade and then you cant even supply them or even give an ETA.
I've esculated this within Sophos but everyone is giving us "there's no ETA."
So I'm hoping posting this will raise awareness and someone with common sense at Sophos will actually realise how much of a problem this is to partners and feedback so XGS can programmed to support older broadcasters for the time being. At the moment we're sat on multiple deployments and unable to go anywhere.
The wireless segment has been heavily impacted by the current global component shortages and all vendors are experiencing longer lead times, not only for access points but also for the Wi-Fi chips and components included in other products, such as firewalls. We expect this situation to continue to be challenging over the coming months.
In case you’re not subscribed already, our Partner Blog is a great resource to keep you up-to-date with the most relevant issues and updates. This one in particular touches on the subject: https://partnernews.sophos.com/en-us/2022/04/products/wireless-lifecycle-and-ap-series-end-of-life-planning/
Your sob story means nothing when the issue was created by Sophos completely disabling older hardware.
If Sophos wants your sob story to mean anything at all, enable the older hardware again until you can actually provide for an support newer hardware. Until then, this is obviously a greedy money grab that Sophos can't actually support.
FYI: Your response is frankly insulting and doesn't actually address the real issue at hand.
Virtual high 5 Neil for that comment!
I've raised this with account manager and senior account manager of the UK sales team about this, they wont esculate it to development.
I understand technology has to move forward, the AP range is old but it functions and did function in v18. The hardware hasn't changed so in theory it should be capable of working. Hell even if there was a legacy mode on 18.5 and 19 to support AP range but meant you couldnt use APX then its a start.
Im really annoyed because of the damage this has caused me with some of my customers, they dont understand the chip shortage, why should they when they are trying to run a business.
For anyone else in this position you could use a UTM as an AP controller and then route that to an XG or XGS but quite a drastic approach.
Why not using Central Wireless? All Access Points are supported there. No need to use the Wireless Controller on SFOS/UTM at all.
So actually there is a solution to this approach, it is Central Wireless. Central Wireless Supports APX, AP15/55/100 at no costs.
You can simply migrate over your Access Points and use them there with one XGS Appliance.
You can do this even now and migrate hardware appliances later.
That's a really interesting idea. I have to confess, not touched Central Wireless as always lead to believe its a paid for service by Sophos account manager. Would you be kind enough to explain in a bit more detail to help me and others reading this, I presume its managed by vlans which in turn the XGS can then handle. Does this work with wifis behind RED/SD-REDs?
So essentially it supports all currently supported Access Points (not the EoL versions like AP30 etc.).
You can do Bridge to LAN, VLAN and Guest Network. Separate Zone is not possible, as separate zone is a concept requiring a firewall. Personally i always recommend to use Bridge to VLAN anyway. It is a better solution for performance and routing decisions.
AP/APX can work behind everything and need simply a HTTPS Connection to Central to get the config. You can configure the AP to still broadcast the Network, if the ISP is down for example.
Central supports Social Login, like Facebook/Google if needed. The Guest network can use a own Voucher system. Guest Network can also be a own network managed by the AP and only allow HTTP/HTTPS (if you do not want to use VLANs for example).
You need a Central Account to use this. By creating a Account, you get all Features/Products enabled for a 30 Day Trial. Those Products will run out after 30 Days and only Firewall/Wireless Management will remain in the Account.
Central Wireless can do Bridge to LAN and Bridge to VLAN on the same time - Not like UTM/SFOS, which has to use VLAN for everything, in case you start VLAN. You can do in Central simply VLAN 2 for Guests and Bridge to LAN for the rest.
Thank you very much for spending the time to reply on this, I cannot understand why Sophos haven't been pushing this as a solution?
Im gonna have to have a dig around now for our old AP55c and hook that up to Central Wireless, see what I can do with it.
Presume it wont work if the AP is on a RED though? I did have a very quick google on this and one thing it states is APs cant be on VLANs to register with Sophos Central.
Sure this will work as well.
As long as the AP can reach Central, it will work. If this is a RED with a tunnel or a ISP router does not matter.
Sophos Central management of WAP's is nice, but it's unfortunate there is no way to disconnect an endpoint from an SSID.
We experienced a infected endpoint on a client WiFi network recently, but Sophos provides no way for us to disconnect it. The only option we had was to disable the SSID. This is quite unfortunate and not a reasonable solution for our clients who provide free WiFi to their customers.
Thats quite a basic feature as well!
The main drive for my customer is to have the clients and firewall in full sync for protection so whilst LuCar Toni solution may not tick all the boxes, its a good start. Just wish Sophos were more customer thinking
You could start a Blacklist of MAC Addresses and simply add the unwanted MAC to the List. This would result in the same "disconnect" behavior.
LuCar Toni where do you manage that list of blacklisted MAC addresses?
Directly in the SSIDs itself.