What do you mean my filter client VPN connections by IP address? Are you trying to restrict the IP addresses that can connect to the MX? In which case, how are you going to determine the IP addresses since they’re likely to be dynamic at the remote end?   If you mean filter what they can access within your network then you can use Group Policy, depending on whether you’re using L2TP or AnyConnect will determine how well this can be implemented (AnyConnect offers the better solution). ... View more

I don’t believe you can do this directly with AnyConnect. What you’ll need to do is RADIUs authentication which returns a Filter-ID parameter that the MX then uses to apply a Meraki Group Policy to the user. Have a look in here under the Group Policy section, https://documentation.meraki.com/MX/AnyConnect_on_the_MX_Appliance.   The other option is once the device is connected to the VPN, find it in the client list on the Dashboard and manually apply a Group Policy to it. ... View more

Yes, the subnet that you’re using for remote access VPN (either AnyConnect or L2TP) only needs to be configured on the AnyConnect or L2TP page, you don’t need it configured on the “Addressing & VLAN” page. ... View more

I believe it’s one of those ‘depends’ answers.   If the rules in the policies are 40 rules with Layer 4 ports then I’d say no, as the minute any GP ACL is applied you’ve exceeded the switch capacity. If you have less Layer 4 rules, say 15 per GP, then so long as all the clients connected to the switch only use two GP ACLs then you should be fine.   The question really is, what’s the definition of a Layer 4 rule? Is it any rule, or just one that specifies a specific Layer 4 port. And that I think is the real question…. ... View more

The MX makes an uplink decision based on the status of the uplinks (I.e. up/down) and the status and performance of the VPN tunnels if you’ve configured SD-WAN routing in your environment.   The choice of the Auto VPN peer to send traffic to is purely based on IP address, and each site has different IP addressing, so if a particular site is unreachable (e.g. the VPN is down) then traffic destined for IP addresses at that site will go nowhere unless another site is also advertising the same IP addresses (which can be done using static routes via a non-Auto VPN path between sites, or if you’re using VPN concentrators as a head-end).   So, if you’re expecting traffic to failover to another peer, then make sure that other peer is advertising the same IP addresses as the primary peer. ... View more

In answer to your questions: 1. Yes, you are missing something. 2. No, you don’t need a static IP address for the Z3, Auto VPN takes care of that.   Regarding the IP addressing the printer will need an IP address for the subnet in the secondary office. Without knowing how your secondary office is currently configured it’s hard to say how best to add the Z3 in. Generally though the approach would be: internet connection terminates on Z3, make sure the LAN addressing on VLAN1 at the secondary office is different to the primary office, enable the primary office MX64 as an Auto VPN hub and add the primary office VLAN to the VPN, enable the Z3 as a Auto VPN spoke, select the MX64 as the hub (don’t select default route) and add the secondary office VLAN to the VPN. Now connect the printer to the Z3 at the secondary office, and also the PC (you no longer need to use the client VPN at the secondary office). And if all that works then the primary and secondary offices should be able ‘talk’ to each other, and so you should be able to print from anywhere on your LAN to any printer at either office. ... View more

If you don’t want to go full MDM, and you’re happy for your users to do some self-enrolment then you can look at using Meraki Trusted Access, https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Trusted_Access_for_Secure_Wireless_Connectivity.   It still requires a systems manager license per device, but might not put such a heavy burden as managing the full MDM. ... View more

From my understanding (which may be out of dat now), Meraki use MaxMind for their Geo IP database. You can use tools on their site (the demo portal) to test the location of up to 25 addresses a day.   I was always of the understanding that the Geo-blocking only works in the upstream (outbound) direction. So if you have traffic coming from a blocked country it will potentially hit the servers (firewall rules permitting), but any return traffic will be dropped. This prevents and TCP connections from establishing, but does mean you potentially see traffic from ‘blocked’ countries hitting your servers - e.g. TCP SYNs, UDP and ICMP traffic. You’d need to check this to be sure though. ... View more

Not sure what your setup looks like, but make sure you only have one link from the switch to each of the MXs, and make sure there is no link directly between the MXs. Double check all your cables too, and make sure they are good. ... View more

No, there is no way to block which IP address the Z3 can establish its tunnel from - that is the ease of the Meraki solution, you don’t need a static IP address. You’ll have to lock the Z3 on the LAN side so that if it is moved somewhere else it is useless unless the right credentials are used on the LAN side - e.g. look at using 802.1x on both wired and wireless.   Obviously, if you know the device has moved you can shut down the VPN tunnel manually. Using this principle you could write a script to monitor the WAN IP address of the Z3 using the API, and if changes then drop the VPN. (Although I don’t think there is an API endpoint to drop the VPN, but you can remove the subnet from the site-to-site VPN which should have the same effect). ... View more

I very much doubt this is going to provide you what you want. When a machine connects to the network it requests an IP address, and you may through a lookup or another system be able to identify exactly who that machine belongs to. However, very few machines will release an IP address ‘cleanly’, most just go out of range and the lease on the server eventually expires, so you have no idea when a machine actually left.  If you want to go down an automated attendance path then you might be better off using a location based system, either using the Meraki location APIs to determine which machines are onsite, or using another application (e.g. who’s on location) that can interface with the GPS locator in a device. ... View more

@RaphaelL Well done on the 250 posts, and glad you’re enjoying the Meraki experience. ... View more

I would recommend that you set up your device and do a wireless survey of the site to see if it provides the coverage you desire. The coverage from the MX-W devices is okay, but not as great as the MRs. The MX-W devices are only Wifi5, and you can’t really move the MX to the ‘ideal position to achieve the best coverage’, more often you are stuck with where the WAN service is delivered and other Ethernet cables connect to the MX. If you’re only talking a handful of users and the site is unlikely to grow then the MX-W may be the go, but I’d seriously consider a non-W MX with an MR, and a small PoE switch if you need it (or the MX68 which has two PoE ports). ... View more

When you are running an SSID in NAT mode all the clients on the wireless side will be using a DNS server of 10.128.128.128. The AP just acts as a forwarder and forwards those requests to the custom DNS servers that you have defined if the hostnames are not already cached. See here https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/DNS_and_NAT_Mode.   What I suspect you are seeing is a browser (e.g. Firefox, Chrome) using DNS over HTTPS (DoH) to server IP addresses defined in Chrome - essentially bypassing the normal DNS mechanism, and your filtering solution. Have a Google of ‘Chrome DoH’ for some more information. Unfortunately this is a difficult one to prevent if it’s on devices you don’t manage. ... View more

Python and Meraki go well together, it’s great for automation. There’s heaps of people here who can lend a hand if you run into any issues. ... View more

Welcome @SkiComputer, and the niceness extends well beyond the APs, it’s all pretty much great. ... View more

I’ve never seen a radiation pattern for the MX-W devices. My assumption has always been that it is roughly spherical to the extent that it really matters - but I may be completely wrong. What are you trying to do that you need to know this? ... View more

And remember that if the warranty response time isn’t inline with your requirements, e.g. you want a 4 hour advance replacement (not something you’d normally want on an access point), or if the warranty is only for a year and you want to extend it, then you can get MerakiNow which is very similar to SmartNet in that it provides hardware replacement. ... View more

@Inderdeep, your link seems to be broken. @hmc250000, here’s the relevant information from Inderdeep’s link… ... View more

Unfortunately you can’t. The MX100 has one dedicated RJ45 WAN port, and then a dual purpose port, which is the lowest numbered RJ45 LAN port. ... View more

Meraki Auto VPN uses random UDP ports for connectivity between sites, it could be that Auto VPN trying to establish connectivity. However, Auto VPN should only try connecting to other MX/Z devices in your organisation. The ports and IP addresses are all contained within the VPN registry, but you’ll need to log a support case to have them look at that for you.   Is it possible it’s just an internal application being NATed out as it’s meant to? You would need to capture Syslog of the flows through the MX and see if you can find the relevant flow. ... View more

I’m sure the documentation is there somewhere, but I’ll summarise based on knowledge and experience, as this is likely better than trying to compare statistics from data sheets.  The first point is that the MX*W and Z3 devices have a standalone wireless solution that does not interoperate with other MX*W/Z3 devices or MR devices. The upshot of this is that if a site grows and you want more coverage then you won’t be able to achieve seamless roaming or the like from the MX/Z to another MX/Z or a MR.   Second point, is AFAIK the MX/Z devices are still only Wifi5 devices, there isn’t a Wifi6 option (would love to be corrected here). Whereas most of the current MR devices are Wifi6.   Third point, if it was me I’d prefer to use MR devices everywhere so that the user experience is as similar as possible, and the management and troubleshooting is as similar as possible too. You also have many more options with the MR range to get the coverage you require, 2x2:2, 4x4:4 and so on.   If it was my choice I’d do MR devices to provide all the wireless capability, then an appropriately sized (non-W) MX (e.g MX64, MX67, MX68, MX75). The only time I’d consider a ‘W’ version of the MX is cost, or if it’s a small office/home office with no more than a few people, and absolutely no chance that it’s going to grow/expand. ... View more

Yes, if you want to tag the internal traffic then creating a new VLAN is probably the easiest solution. You can the leave he APs on the native VLAN (VLAN 20), and change the SSID for internal clients to use VLAN 30. You’ll also need to configure a new DHCP scope for VLAN 30 and, and if the DHCP server isn’t actually on VLAN 30, then configure a DHCP relay/forwarder on the Layer 3 interface for the VLAN.   There shouldn’t be any problems leaving it as it is. As has been said though, it’s recommended to keep management traffic on its own VLAN. ... View more