If you had policy applied directly to an iOS device and they update to iOS 14 then you’ll see the ‘old’ device (I.e. the device’s real MAC) will never connect to the SSID again, and it will appear as a ‘new’ device (I.e. using its randomised MAC). So yes you will need to re-apply policies to the devices. The only way you can avoid this is if you can get the users to turn of MAC randomisation, or turn it off using an MDM (if you’re using one). ... View more

@Boyan1 You’re able to have multiple organisations linked to a single login, and when you login you get to choose which organisation to administer. When you’re in the Dashboard you also get an additional drop-down menu above the network drop-down menu of the left that allows you to swap between organisations.  ... View more

@IT_Tropolis I’ve never come across an easy solution to this problem. It’s one of the reasons why I try to avoid the 192.168.x.x networks for anything to do with a corporate/office network. If they need to access Local LAN resources at the same time as being connected to the office via VPN then one of the networks IP addresses has to change, or be NATed.   Maybe you can provide them a small Meraki MX/Z device for use at home (via AutoVPN) and enable VPN subnet translation, https://documentation.meraki.com/MX/Site-to-site_VPN/Using_Site-to-site_VPN_Translation. You’ll need Meraki Support to enable it. However this will most likely then cause you other issues with DNS hostname to IP address mappings. As I said, unfortunately no easy way to fix this one. ... View more

Hi @arjgoodwin, welcome to the community. Are you able to explain what you are trying to do? It might also be with starting a new topic otherwise people might think your adding to the existing topic. ... View more

Hi @Corsani, this is to do with the way the browser handles HTTPS sites. When you put something in the walled garden then Meraki allows access to it before the user has authenticated, so it just passes the traffic straight to the site. This is exactly the same for whether you're accessing an HTTP or HTTPS site. It's just as if the Meraki didn't exist - hence why it works.   In the scenario where you are trying to authenticate you need to think about what is happening (this is going to be a pretty high-level explanation, but should help you to understand it). In the case of an HTTPS request you're asking to fetch a page from bing.com using an encrypted connection - that's what starting the URL with HTTPS means. So your browser goes out to get the public certificate from bing.com to encrypt the connection. However, at this point the Meraki device intercepts it and can't do anything. It could pass back the bing.com public certificate, but then it doesn't have the private key so can't encrypt/decrypt the messages. Or it could pass back its own certificate and become a 'man-in-the-middle', but then the browser will generate all sorts of errors because the certificate name won't match the website name (i.e. bing.com). And this is where the problem lies, there is no easy way to do web-based authentication for HTTPS based sites. The user needs to first go to a HTTP (unencrypted) site to authenticate successfully, and then once that's happened all should be good. ... View more

Sounds like the SSID configuration is probably not the problem. You mention the AP has Static IP with no VLAN. If the AP has a static IP address then it shouldn't be using DHCP. If it is using DHCP then it means that its failed to contact the Meraki cloud using the statically configured IP address. Does the AP have DNS services and an IP gateway configured correctly too? (Or if you're using reservations on the DHCP server, just move it to DHCP). ... View more

What 'Client IP Assignment' are you using on the SSID - I'm assuming NAT mode. So the traffic is intended to go directly from the AP to the ASA and then out to the internet. Any you're seeing the "This device is using a DHCP IP address...." in the Meraki Event Log for the AP? ... View more

What are the configurations of your SSIDs? Where are clients getting their IP addresses from? Even if you configure the switch port as an Access Port you need to remember that the MR is still effectively a Trunk Port. If you use an IP addressing mode on the SSID that potentially tags traffic on the port (e.g. Bridge Mode, Layer 3 Roaming) then you might be seeing unexpected behaviour that has nothing to do with the Management IP address and VLAN of the MR.  ... View more

Exactly what @cmr said, but I'll add a little to that. A lot (like really a lot) of web traffic is encrypted or dynamically generated and so unable to be cached anyway. It may be that you get some benefit to it, but I'd say its unlikely, and very dependant on what's being downloaded. Also worth noting that the MX84 and MX100 had 1TB drives for caching, the MX250 and MX450 only have 128GB drives (although they are SSDs) - does that say anything? ... View more

@ManolisFr if its an unmanaged device then you'll likely be having the same issue I described for the MX64. If the Synology is using both its NIC MAC addresses, but only a single IP address then you will be seeing the same IP with two different MAC addresses, which triggers the alert on the MX. Have a look at the MAC addresses that the MX is reporting in the Event Log alerts and see if they match the MAC addresses on the two NICs of the Synology.   Unfortunately, there may not be a solution to this one. If you're using Synology's Adaptive Load Balancing this may just be the way it works. Your solution may be to either live with the error, unplug one of the cables from the Synology (i.e. break the network bonding), or to purchase a switch that supports LACP and use LACP for the link aggregation. ... View more

So far as I'm aware the cellular interface on the MX67C/MX68WC are still only for failover in the event that your WAN interfaces both go down. Therefore, L2 is still only 1 in your scenario (assuming you're only using WAN1, and not WAN2) as the cellular link won't kick-in unless the link on WAN1 fails. ... View more

What model is the gigabit switch? Is it configured with link aggregation? ... View more

@ManolisFr what are you connecting your Synology NAS to? If its directly to the MX64, then the MX64 doesn't support any form of NIC/network bonding. It is possible that the Synology is using both network links with the same IP address. This will likely result in the Meraki seeing an IP address being associated with two MACs, and hence the error. I would try 'un-configuring' the network bonding on the MX if the Synology is connected to it.   The server is probably behaving slightly smarter - i.e. keeping each IP address on the same NIC - which is why you're not seeing alerts from the server. ... View more

@GFrazier the lack of STP support on the MX is good to remember, but if you only have a single link to it from each switch then it doesn’t make too much difference - if you have multiple links you need to consider the spanning-tree topology.   With your plans, it generally sounds good, but a couple of things to consider:   Why not stack all three switches in the MDF (assuming they’re located together, and the same model). You could use 3x MS225 if you only need basic Layer 3 capabilities - they’ll support up to 16 VLAN interfaces and 16 static routes. You can then use the stack as your Layer 3 gateways. Having all switches in a stack in the MDF would allow you to dual connect the MX and the IDF switch stacks to provide improved redundancy - in physical stack you can do cross switch LACP aggregation (this is only to the MS, the MX doesn’t support LACP so you need to rely on STP for redundancy). Relaying DHCP to the MX should be fine; the MS225 only supports DHCP relay (and Azure doesn’t allow DHCP servers).   ... View more

As always (annoyingly), it depends.  If your network is generally a flat Layer 2 network where the communications is generally between clients on a single VLAN, then having the two switches connected to the one makes sense, as a lot of the traffic won’t need to hit the MX (and so reduces the load on the MX).   If however you have a well structured network with separation between server and clients so that the majority of traffic goes through the MX (as it’s a acting as a Layer 3 gateway) then it probably makes little difference as the traffic is traversing the MX to reach the other VLANs anyway.  Generally I’d take the approach you currently have, MX to MS, then that MS to the other MSs, but if you using the MX for Layer 3 (since the MS220s are Layer 2) I don’t think there’s much difference either way. ... View more

@buschtrommelXXL Glad to hear you got it working.   Here are the guide lines for setting up the STP guard features:   BPDU Guard should be enabled on all end-user/server access ports to avoid rogue switch introduction in network Loop Guard should be enabled on trunk ports that are connecting switches  Root Guard should be enabled on ports connecting to switches outside of administrative control These come from this document, https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MS_Switching/General_MS_Best_Practices.  However, between the MX and MS devices I wouldn’t enable any of the STP guards since the MX doesn’t participate in STP, it just forwards any BPDUs it receives. ... View more

Normal your native VLAN is just one of your VLANs - quite often it’s the Meraki management VLAN so that your devices can connect to the internet with any pre-configuration. But if you prefer to use just an empty VLAN you can do that too. Just remember to configure the same native VLAN on the switch end of the trunk too. ... View more

What’s the native VLAN on the trunk at the moment? Can you leverage that at all? Pre-configuring 50 APs won’t be fun. If you can use the native VLAN for cloud management traffic only, maybe you could use the Alternative Management Interface for all other management traffic (e.g. RADIUS, Syslog) - and that one you can define for all the APs. ... View more

@thomasthomsen what’s the use case? I don’t believe there is an easy way to do what you’re asking through the Dashboard. Normally you’d want to keep all your APs on the native VLAN so that when you add another one it ‘automagically’ finds the internet and connects to the Dashboard. Otherwise you’ll need to preconfigure every AP before you deploy them anyway, since their first comms will be on the native (untagged) VLAN. ... View more