Meraki

Mloraditch

Same answer even if a different local subnet. My recommendation is to bite the bullet and fix your devices to be setup so that you can easily make changes in the future. The local dns option is new and definitely worth exploring.

Mloraditch

If the MX100 itself generated such a request you would may not see it in the logs. I'm not sure of exactly how the inline scanning works, but I suspect it doesn't look at Control Plane traffic. Only support could definitively answer why the Z3 is generating such a request (and if it's actually the Z3)

Mloraditch

The MX will respond to DNS requests but it's only a forwarder and it will only forward the Requests to the DNS servers programmed as the DNS servers for it's WANs which generally must be public DNS servers. The WANs can not use a DNS server over the Auto VPN.

Mloraditch

Are you saying you have a Z3 behind an MX100 and of the two entries above one is sourced from the Z3 and blocked and one is from an end client and allowed? It's possible the one is being blocked because its going to an internal server vs the internet. Support may be able to give more insight into how the rule in question operates. The public documentation on the rule is not super detailed: https://www.snort.org/rule_docs/1-48666

Mloraditch

So if your MX is 10.0.0.1 and you set as I've described it will use whatever is the DNS for the WANs which generally must be a public DNS server. If you need 10.0.0.1 to forward to an internal DNS server you control you can't do that. You will have to touch the static devices in some way and update them to use the new DNS server. Preferably to DHCP with reservations if necessary to avoid this in the future.

Mloraditch

What you want to do is not possible. However if a Meraki MX is doing DHCP and you select proxy to upstream DNS as your dhcp server option, the MX will respond to DNS requests. https://documentation.meraki.com/MX/DHCP/Configuring_DNS_Nameservers_for_DHCP

Mloraditch

In theory this should work: https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Extending_the_LAN_with_a_Wireless_Mesh_Link You would just need to use two injectors and then connect their data ports to each other instead of having a switch. I personally would want a switch so I can fully power cycle the AP and only need one power plug, but it may not be worth it depending on your needs.

Mloraditch

Per the documentation for this API: https://developer.cisco.com/meraki/api-v1/delete-network-meraki-auth-user/ You need to specify the delete parameter and if the user is in multiple networks you may need to run it multiple times to deauthorize from all and then it will delete on the last network.

Mloraditch

Is your network set to your correct time zone? If so, what type of client tracking are you using? If you use MAC tracking and have a layer 3 switch, your client data may be incorrect. You need to use IP tracking or if your layer 3 is Meraki Unique Client Identifier. https://documentation.meraki.com/MX/Monitoring_and_Reporting/Client-Tracking_Options If everything is set correctly for your environment, compare the mac of the client in the dashboard to the client you are checking. Client naming is not an exact science and you may not be looking at the right end device.

Mloraditch

I don’t have anything like this setup, but I suggest calling support. There is no customer side logging of this and only they can possibly help identify any issue.

Mloraditch

I'm not clear on what you are asking. My best guess is you want a vpn client user to only be able to access a certain internal subnet? You could do split tunnel and only permit them access to that subnet. https://documentation.meraki.com/MX/Client_VPN/Configuring_Split_Tunnel_Client_VPN or for AnyConnect: https://documentation.meraki.com/MX/Client_VPN/AnyConnect_on_the_MX_Appliance#Client_Routing

Mloraditch

What i've googled indicates that your macbook needs to talk to the printer not to the internet. Are the printer and macbook on separate vlans? Are you able to setup the printer by IP? It may be that by default it does airplay printing and needs bonjour forwarding setup. https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/Bonjour_Forwarding Several possibilities here and Dymo support may be able to provide clarification on what exactly is needed so that we or support could provide clarify on what configs are needed.

Mloraditch

No the models are not compatible for stacking. That's pretty much universal in switching. Only like models can be in a physical stack together. The only part of the settings that you can just move are the Layer 3 settings (and they would need to be in the same network for that to work). Everything else has to be cloned either manually or via the API.

Mloraditch

It could be this fix: Fixed a bug with client analytics on Access switch ports that prevented clients from being correctly listed in Switch Summary, Switch Ports, and Client pages If you've got an open support case tied to a bug, they should be able to confirm if your case matches this. Or if you've never contacted support you can open a new case and they should also be able to match it up.

Mloraditch

A few extra bug fixes from 17.2.1 and some different known issues. Important notes This version's IOS image is based on 17.12.4 CCO. Upgrades to this version will result in a full system reload. New feature highlights Client Analytics Device Uptime for MS390s EEE (Energy Efficient Ethernet) Support Multi-auth with support for guest/failed/critical RADIUS Caching Support for Multicast in Live Tool VLAN to SGT mapping General fixed issues The local status page has been enhanced to enable managing the allowed VLANs range using a single configuration option Fixed a bug with client analytics on Access switch ports that prevented clients from being correctly listed in Switch Summary, Switch Ports, and Client pages Resolved an issue that caused MAC flapping and packet loss on downstream switches Introduced measures to significantly decrease occurrences of the Meraki container becoming trapped in a reboot loop while switches maintain data traffic flow. This scenario may still occur in rare cases. Corrected an issue that caused stack ports to be incorrectly displayed as "Disconnected" after a stack member was rebooted Fixed a bug that caused the Static Gateway IP to display as '0.0.0.0' in the L3 Routing Switch tab Resolved an issue that occasionally prevented the uplink port from being identified correctly on the Dashboard. This issue did not affect device connectivity. Fixed a bug that caused a brief period of L3 traffic loss after the active member of a stack failed over All new LAG configurations will block redundant links if the connected device is not configured for LACP. This change fixes an issue where switches would sometimes move LAG ports to an active forwarding state prior to LACP convergence, creating the potential for loops. The change does not apply to existing LAG configurations. Ms390 fixed issues Resolved an issue that prevented the application of fixed IP assignments if the IP being assigned had an active DHCP lease Fixed a bug that would infrequently prevent MS390 stacks from converging after a failover C9300 known issues Some C9300X stacks have been reported to fail due to memory exhaustion, requiring an ios restart to restore service Ms390 known issues In rare circumstances, MS390 stacks may display UDLD loop detection alerts that cannot be cleared by cycling the looping port MS390s may display an alert, "A power supply is offline" when a PSU isn't installed in the second slot

Mloraditch

I suggest working with support at this point. You could be encountering a bug.

Mloraditch

Does the FQDN always resolve the same? There are limits to FQDN support detailed here: https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Firewall_Settings#FQDN_Support It's somewhat limited and not as well built as other vendors. The MX only learns FQDNs via client requests and if those requests aren't in the clear (i.e DoH) or previously cached it won't see them. And if the record in question provides round-robin responses or is otherwise dynamic, it may not properly track the FQDN.

Mloraditch

There are no limits or licensing restrictions. I've only ever seen misspellings be the issues with the emails. Have you tried the resend option? I suggest contacting support to see if they can see anything on their side.

Mloraditch

There is not. See here for how the source is selected: https://documentation.meraki.com/MX/Monitoring_and_Reporting/NetFlow_Overview#NetFlow_Export_Scope

Mloraditch

Route Tables would not be wiped out. They are not part of the managed deployment, at worst you might have to adjust the ip where your routes point to. I would not think you would have to adjust their vnet assignment. Especially if you already deployed as NAT mode.

Mloraditch

The only way to perform the reset is with the button. Support may be able to guide you through some undocumented other uses of the reset button. I recall some products do certain things if you hold them for even longer, but it may be necessary to get an RMA.

Mloraditch

SIP ALG is not configurable with Meraki and doesn't exist. That's important to know. Otherwise what @DarrenOC is the right path to go down.

Mloraditch

1) It depends on how you want to set it up. If I'm NATing my guest traffic to the AP, I set up the rules on the APs. If I'm dropping off to VLAN I setup the rules in a Group Policy on my MX associated to that VLAN. 2) Wireless would be processed first then MX rules if you had both. 3) As wireless is processed first that would block traffic to any RFC1918 subnets.

Mloraditch

I've never seen anything like this publically or as a partner. This may be something to contact your AM/SE on. If you are trying to reach Simone directly, your AM/SE may be able to put you in contact.

Mloraditch

They may not have completed properly, or may be reporting incorrectly. You may be able to check from the local status page to see the current version, but regardless Support would need to tell you for sure what needed to be done to correct.

About Mloraditch

Mloraditch

Matthew Loraditch

Community Record

Badges