Is 6 GHz enabled in the Radio-Profile? ... View more

With that approach, you build a physical bypass around your firewall. With the slightest mistake by the ISP your internal network is openly exposed to the internet. I would not do this. ... View more

General rule: You need a /29 from your ISP to have the needed addresses for MX1, MX2, and optionally the virtual IP. If you only have one IP, you could place a NAT router in front of both MXes and use a private transfer network. But that is again a single point of failure. https://cyber-fi.net/index.php/2024/02/19/connecting-your-meraki-mx-to-the-internet/ ... View more

No, with OWE, each user has unique keys, and one user can not decrypt the traffic of another. The only possible attack is that the attacker gets active into the connection (MitM). Then the traffic can bee seen natively. But the credentials are still protected if the splash page is delivered over HTTPS. ... View more

Necesita un software que pueda hacer esto. Un software que se ejecuta en línea y es gratuito para hasta tres AP sería Hamina: https://www.hamina.com ... View more

Can you share a screenshot of how you do the renewal? ... View more

If the Firewalls are Meraki MX, you at least need a separate network for them. The rest will work as you want. I would still put all devices of one site into a separate network. Also, the APs. It will reduce the overhead and give you better visibility. The only reason to keep the APs in one network would be that you have a roaming path between the sites and want to do fast roaming between the sites. ... View more

It's not really about the band. My advise is to use WPA3-Enterprise in both 5 and 6 GHz. With that you don't need Transition mode. ... View more

Are you sure that you really need transition mode? If your PCs are not stone old, they likely support "pure" WPA3. With Enterprise Authentication, the difference is not that big to WPA2. I would add a new Test-SSID with WPA3 and test your oldest devices to check this. ... View more

@BlakeRichardson Philip will report when he finds out about the next level. 🙂 ... View more

Expected for 2028, I would not expect to be happy with only 30W … But likely also not a IEC 60309 plug. 😀 ... View more

My 9178 doesn't even announce Wi-Fi 7 without PoE++.    For a new rollout I would go for devices that support more than 30W. And if the MS150-X models are considered, it's worth looking into 9300L which are heavily discounted at the moment and are only slightly more expensive than the MS150-X. ... View more

Mist was also quite late with Wi-Fi 7. I think Ruckus was first, but Extreme also says they were first to market.  Yes, Ubiquty and the HO devices like TP-Link also came early. ... View more

I am connected with Wi-Fi 7 on my phone (iPhone 16 and Pixel 9). These are my only devices that are new enough. Now, I am hoping for the next MacBook Pro. ... View more

Then the solution is 802.1X with EAP-TLS as already mentioned. Every company device is enrolled with a certificate that is not exportable on the end device and only these devices are allowed to authenticate. Or, all other devices that don't authenticate through a certificate get the "only-Internet" VLAN assigned. ... View more

That was just when the old core was connected. When thinking again, I am not sure anymore if this symptom will be seen as the MX is transparent for the Catalyst to Catalyst communication. In general, the more separation we have between these worlds the better. ... View more

Yes, as mentioned, the native VLAN on the MX is existential to forward the BPDUs to the MS switches in this scenario. By running PVSTP on the Catalyst side, you create a loop through the combined infrastructure. It's not for all VLANs, but enough for the meltdown. My advice would be to configure the native VLAN as the Meraki Mgmt-VLAN with no other devices in there in the infrastructure on the left. But that will likely still cause inferior BPDUs. Can you use completely different VLANs on the old and the new side? That would give some extra separation when you only allow the needed VLANs on the MX trunks. ... View more

I assume you won't achive this reliably with the build in tools. One option worth a test is to have two group policies in the WLAN, one default without splash page and one with a splash page. The later gets assigned based on the end device:   For the "if they managed to know the password": Normally the users can always find out the passphrase. This is only forbidden when the WLAN profile is pushed with an MDM like Meraki Systems Manager. ... View more

With a redundant setup, the most important part is the enabled native VLAN on the MX: https://cyber-fi.net/index.php/2022/03/13/how-to-connect-the-meraki-mx-to-ms-switches/   If you have the same VLANs on all switches, you will face some extra challenges with unusual BPDUs as each Switch will see multiple other switches on each uplink: https://documentation.meraki.com/MX/Networks_and_Routing/MX_Layer_2_Functionality#Spanning_Tree_Protocol_(STP) ... View more

There are multiple ways of interpreting what you write. Is the "point to point connectivity" between core and distribution just the link? Then you can trunk the same VLAN to that switch and use the same subnet behind that switch. The rest of your network influences whether that is a good idea.   But if "point to point connectivity" means that you have a routed link between core and distribution, then you can't use the same subnet on the other side of this link, at least not without additional struggle.   Why do you want to use the same subnet? Do you have a roaming path at all between these areas? Perhaps one of the other operating modes are more useful where you don't need the same subnet. ... View more

Inspired by @Bon_clay, a heart in Hamina Network Planner with three Meraki CW9176D1:     ... View more

That is perfectly fine and very common! ... View more