Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Become a member of the Cisco Meraki Community today
Get answers from our community of experts in record time.
Join now- About General-Zod
About General-Zod
General-Zod
Getting noticed
Member since Sep 5, 2017
a month ago
Kudos given to
Community Record
48
Posts
40
Kudos
3
Solutions
Badges
Dec 7 2020
12:45 PM
1 Kudo
Greetings @GregoryW Can you please disable NATing on your fortigate IPsec firewall policy. Local>remote Your IPsec interface on the fortigate doesn’t have a ip associated with it (unless you have configured one) so the NAT function won’t do you any good. This would also explain why traffic initiated from the Meraki to Fortigate is working. The fortigate IPsec firewall Policy remote>Local should also have NAT disabled, however it’s still working as the egress interface “local-lan” does have a ip attached to its interface. make sense?
... View more
Jun 29 2020
8:55 PM
Generally speaking, simply having a device that is unused in your inventory won't go towards a license count. In the case of MX's, if you go down the HA path and add the 2nd MX to the same network with a existing MX you will still be within the license limits as you don't need another license if you setup a MX HA pair. Hope this helps
... View more
Jun 29 2020
7:38 PM
1 Kudo
Hi @Noffal Licenses are applied to Orgs not devices. If you purchased another MX64 to use in the event of a failure you could simply have the device sitting in the inventory (not assigned to a Network). If the time comes you can simply remove the faulty MX from the network and add the new one from inventory to the network in question. On a side note, if you going to the expense of purchasing another MX for business continuity why not create a HA pair (2 x MX64 - Active-Passive). One of the good things if you go down this path is that you don't need another license. Only 1 ENT or ADV license is required for MX HA setup. You'll need to be able to span some vlans/ports on a switch to cater for the connections but at least you will have automatic redundancy. https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair Hope this helps
... View more
Jan 9 2020
3:16 PM
2 Kudos
Hi @samgbuyi If the src and dst are on the same vlan that resides behind the MX there would be no enformement being done on the MX as there is no L3 involved. I believe you problem is in relation to something else. I'm certain you will have the same result if you unplug the lan interface on the MX from your switch. Perhaps check the server itself.
... View more
Dec 21 2019
3:02 PM
1 Kudo
I have seen this before on a MX using its dhcp mechanism. There was a rouge ip phone that kept changing the last part of its MAC address and it kept consuming IP’s until the pool was exhausted. The dashboard however showed plenty of available addresses. After a call to Meraki support they were able to dig deeper and they could see that the pool was indeed exhausted. It is my understanding that the dashboard only shows successfully accepted dhcp offers. The rogue IP phone in question just kept flipping the last part of its mac and exhausted the pool. Sadly whenever the event occurred I wasn’t available to perform a capture. Hope this helps. cheers
... View more
Dec 10 2019
7:51 PM
Actual device uptime in additon to current dashboard checkin uptime. For MSP accounts, have the Orgs name in the subject line with the notification message. Able to add "inbound" firewall rules to IPSEC VPN tunnels
... View more
Nov 20 2019
12:59 AM
3 Kudos
Negative, MX’s participating in HA are only active-passive, at least in the current software. The active MX can however utilise dual wans simultaneously, if applicable. hope this helps
... View more
Sep 10 2019
2:42 PM
1 Kudo
The X in MX might refer to Extensible Threat Management, often referred to as XTM. This essentially is a extension of Unified Threat Manage (UTM). cheers
... View more
Jul 29 2019
4:43 PM
1 Kudo
I'm assuming you have tried to do this and it failed? However I'm able to do this with no problems, see screenshot.
... View more
Jul 28 2019
11:57 PM
4 Kudos
Greetings, You can specify multiple source IP's in the outbound VPN firewall policies. Looks like you're not entering the IP address correctly (from your screenshot). Each IP must be separated by a comma. See below:
... View more
Jul 11 2019
7:27 PM
When I first got on board the Meraki bandwagon the term enterprise license to me implied Enterprise=Ultimate license. However this is not the case, took me a while for that to sink in. At the end of the day the devil is in the detail and the link I provided shows the differentiation. At the end of the day its just a name. As mentioned before, if you have the advance license you reduce your risk in being exposed to threats. They key takeaway here is the word "reduce". To boot, just because you have the Adv license it does _not_ mean your immune from threats either. It all comes down to the Org's security posture. cheers
... View more
Jul 11 2019
6:37 PM
1 Kudo
Greetings, See below link which shows the differences: https://documentation.meraki.com/MX/Other_Topics/MX_Security_Appliance_FAQ Adv license offers "additional" security functions which when implemented correctly reduce your threat landscape. Hope this helps. Cheers
... View more
Mar 18 2019
4:45 AM
If they’re compromised, absolutely. I would block the cameras internet access if it doesn’t prevent their operation. i would also upgrade and factory reset them whilst referencing any security advisory’s from the camera vendor. cheers
... View more
Mar 15 2019
6:46 AM
1 Kudo
Hi, it would be overkill to use group policies to only block internet traffic for a single host (camera) you would be better off just using the standard firewall. it would be wise to investigate why the camera initiates connections to the internet. Most probably to check into some vendor service. You could also look at restricting the bandwidth for said device using the very group policy you have already created in the traffic shaping section. hope this helps
... View more
Mar 8 2019
7:19 PM
Alternatively if your AP’s are all on the same management vlan you could configure that subnet to flow preference out wan2. When doing dhcp with NAT on a MR all clients src NAT to management IP of MR pre egress. In this scenario the MR would also talk to the dashboard using WAN2. food for thought cheers
... View more
Dec 4 2018
5:44 PM
4 Kudos
SDWAN is comparable to a shopping centre at a location which has many roads leading to it. Some of these roads are sealed, some are dirt. Generally speaking, the sealed roads provide a quicker path to and from the shopping centre. In order to best distribute traffic, the 4 wheel drive vehicles leave the shopping centre via the dirt road and the normal vehicles leave the shopping centre via the sealed road (scenic path). Whilst the luxury cars leave the shopping centre via the more direct sealed road. However, on rare occasions during bad weather some of the roads become flooded which greatly reduces or completely cut off access. When such events occur an alternate path is chosen. For example, if the luxury cars are able to but greatly impacted or totally unable to go via the most direct sealed road due to flooding, they will try the scenic route sealed road followed by the dirt road until a more reliable path is viable. Each luxury vehicle will check the status of the roads as they leave the shopping centre. Alternatively if the dirt road and sealed scenic road is flooded, the 4 wheel drive vehicle will go via the direct sealed road, again each 4 wheel drive will check the status of the roads before they leave the shopping centre. WAN's = Roads (Sealed Direct, Sealed Scenic, Dirt) Applications = Cars (Luxury, Normal, 4x4) Hope you enjoy the analogy Cheers Anthony
... View more
Kudos given to
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 8878 | Dec 7 2020 12:45 PM | |
| 3442 | Jun 29 2020 7:38 PM | |
| 3158 | Jul 29 2019 4:43 PM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 4 | 3200 | |
| 4 | 45836 | |
| 3 | 12815 | |
| 2 | 14354 | |
| 1 | 8878 |
© 2025 Cisco Systems, Inc.
