Meraki

BHC_RESORTS · ‎Nov 17 2017

We run a very layered, security focused approach on our networks. We run mostly hotels, but we also use the Meraki stack for our corporate office and other business ventures. Network Wide: Alerts - setup alerts for rogue AP, any device going offline, DHCP pool exhausted, rogue DHCP server detected, malware is downloaded/blocked. General - collect destination hostnames. Change default local credentials. Add a syslog server to your environment for further monitoring and post incident logs. Enable SNMP v3 with secure username/password. MX Setup: VLANs. Segregate traffic based on activity. Production network, guest network, CCTV network, etc. Create ACLs to prevent inter-vlan traffic where not desired. DHCP - Only offer DHCP on networks where it is required, and limit scope. Activate DHCP snooping and rogue DHCP server detection. Firewall - Prevent inter-vlan traffic when not desired. Apply appropriate Layer 7 rules, such as filtering out P2P. Only create port forwarding for absolutely required services, limit connecting IPs to only those needing to access. Active Directory - Integrate to allow better tracking of resources and for any post breach research, if necessary. Also create groups to allow specific filtering profiles (management, line staff, etc.) Threat Protection - AMP Enabled at all times. For IDS, Prevention and Security methods selected. Content filtering - Unless otherwise overruled, standard set is to block: Bot Nets, Confirmed SPAM Sources, Keyloggers & Monitoring, Open HTTP Proxies, Parked Domains, Peer to Peer, Phising and Other Frauds, Proxy Avoidance, SPAM Urls, Spyware and Adware. This is also done on our guest networks for enhanced protection. For production network, add: Adult and Pornography. Choose full site list instead of Top sites only. Security Center: Review on a weekly (or shorter, depending on your needs) interval. Setup scheduled email reports accordingly. MR Setup: Access Control - Even for guest networks, recommended setup is for WPA2 (only). Enable Adaptive 802.11r. Access Control - For secure networks, authenticate with RADIUS and use Systems Manager Sentry to ensure only authorized devices are connected. Access Control - Make sure appropriate VLANs are being used, and guest traffic is prohibited from reaching any other subnet/network. Firewall - Deny Wireless clients accessing LAN as appropriate. Enable L7 rules for blocking P2P. SSID Availability - Considering disabling unneeded SSIDs during closed times. Enable SSIDs on APs only where they are needed. Air Marshal - Contain rogue APs seen on the LAN PCI Report - run at regular intervals Physical setup - ensure APs are mounted in locations not easily tampered with, or if within reach, in a secure box/environment to prevent physical tampering. MS Setup: IPv4 ACL: Setup as appropriate for your organization Access policies - Setup SME Sentry for connected device and guest VLANs - use either Meraki authentication or ideally, your RADIUS server. Switch Ports - disable unused ports. SME Setup: Security Policies - Create policies for different devices (stationary vs mobile for example). Security Policies - Enable screen lock, login required, firewall enabled, disk encryption, antivirus running, passcode lock, device is not compromised, and minimum OS version check. Geofencing - Enable appropriate policies based on device. Very limited for stationary devices, more broad for mobile depending on the user. Setup alerts to notify admins when fence is breached. MDM Settings - Require password to removal profile. Set appropriate restrictions, password policies, WiFi sentry, etc. as needed based on the business. This helps keep us safe, in addition to the non-Meraki procedures we follow. Every bit of the layer helps!

BHC_RESORTS · ‎Oct 10 2017

We have some of our APs around 200m from the ocean - 72s and 74s. No issues here other than they start to look pretty terrible after a year (but that isn't Meraki's fault). They have survived rain, moisture, birds, etc. Be sure to properly ground them, it isn't just for lightning strikes!

BHC_RESORTS · ‎Oct 5 2017

@alyssafriesen wrote: I have 2 Meraki APs advertising the same SSID, but they should work in conjunction as a mesh, right? Not necessarily. Depends on how you have it set up how gracefully the clients roam.

BHC_RESORTS · ‎Oct 5 2017

RSSI looks pretty good, so I don't think weak signal is to blame here. What does the RF environment look like? Is it congested? Looking at the logs, the client connects incredibly briefly then disconnects. Any kind of splash page, radius, or anything else like that set up that is preventing it from staying connected? Edit: Just realized all the times are almost the same, every day. What is occurring at around 2:00 CDT? Something around that timeframe is causing loss of connectivity.

BHC_RESORTS · ‎Oct 5 2017

Phone soap! @CarolineS was kind enough to send this our way for our contribution. It's a phone soap! Pretty slick little device, which has a UV light in it to sanitize your phones (or whatever else fits in there I suppose). We put it in our lab for all of our techs to use, so we are all excited about it! Community contribution certainly does have its rewards sometimes!

BHC_RESORTS · ‎Oct 5 2017

@Bryan_Vukich wrote: I've been waiting for IPv6 support for years now, and there's been little or no apparent movement on it. I'd be happy with a separate beta firmware branch that has it enabled even if it's a bit broken. This. All of our WAN providers have IPv6 being given to us, and we can't use it.

BHC_RESORTS · ‎Sep 21 2017

@PhilipDAth wrote: If you log into the Meraki console and go Help/Replacement Info it will show you any devices that are affected. You don't need to do anything - Meraki already knows exactly who you are. They sort the devices so that those most likely to fail the soonest get replaced first. They will email you about arranging the swap out. Pretty much you don't need to do anything to start the process. Cisco Meraki initiate the process for you. I knew one of our MX84s was affected, but never knew about this page. Nice!

BHC_RESORTS · ‎Sep 21 2017

There has been a nagging bug where content filtering was based on IP, not DNS - so it would block servers hosting many websites. Could have been related.

BHC_RESORTS · ‎Sep 20 2017

I've been requesting this feature for years now...

BHC_RESORTS · ‎Sep 15 2017

Have you had a look here? https://documentation.meraki.com/MX-Z/Content_Filtering_and_Threat_Protection/Safe_Search_and_its_effect_on_Google_Apps_and_Google_Search

BHC_RESORTS · ‎Sep 13 2017

@ARiK_LeV wrote: Why don't we all just submit a High Priority ticket for this issue. If they get the same requests for the same issue it will kick this up the ladder pretty quickly. Submit one ticket per Org. Lots of cut and paste. Seems silly to report an issue you don't have. Also, there is the old tale of the boy who cried wolf...personally I only submit tickets for issues I personally experience, but that's just me.

BHC_RESORTS · ‎Sep 7 2017

@mnw wrote: So your response is different from the other person responding. I find it hard to believe that one would have to pay $30 for every chromebook, windows computers, iPads, and other devices we have in the dashboard. Of course, that is an annual license also and not a one-time charge. This is funny, because I have talked to two Meraki resellers and their answer was different also. Ah, I misread your original post. Clients connected to your network, no, you do not need a license. Clients enrolled with SME, yes, you need a license.

BHC_RESORTS · ‎Sep 7 2017

@mnw wrote: We have a Meraki network with 1,500+ devices included in the dashboard. I want to use the licensed system manager. Do I have to purchase a license for every device in my dashboard or can I selectively license only the iPad devices? You need a license for every active device. With APs/hardware, it is pretty easy to move one out of a network to free up a license. With SME, that would be a pain. On a side note, with that amount of licenses, you should have a VAR that will get you very aggressive pricing. I'm just spittballing, but I wouldn't pay more than $30 a license for a 1 year term on that quantity. You could probably get it down a little more at end of quarter. Do you have a VAR you are working with? If not, let me know and I can PM you who we use.

BHC_RESORTS · ‎Aug 31 2017

@PentagonSystems wrote: Hi Everyone, Did anyone else notice that if your MX is set up to send alerts to administrators whenever configuration settings are changed, you can go into the alerts settings (if you have the appropriate privileges), uncheck that setting, save the setting, make whatever changes you'd like, go back into alerts, check the setting again, save, and log out, and no alerts will be generated or sent? Sure you can still see the changes made in the event log, but I would think that, at a minimum, admins would get an alert when the 'configuration settings are changed' is changed from checked to unchecked. Am I imagining things, or is this a security/audit concern? I'd suggest sending it to security@meraki.com as mentioned here: https://meraki.cisco.com/trust#srp

BHC_RESORTS · ‎Aug 31 2017

@cantechit wrote: Subject says it all... We need proper IPV6 support in the MX Platform... Even IPV6 tunnelling doesn't work at this point. Anyone else have soem comments? Can't agree enough. Specifically, on the WAN portion.

BHC_RESORTS · ‎Aug 30 2017

@Jak_Medina wrote: Hello, everybody! I am Medina. I live in Brazil, and currently, i been working with more than 300 Meraki MX64 clients. In this community, I want to become a contributor for all, bringing problems, experiences, and CASES, which I have facing day by day with my managed networks. I want to contribute with everyone, in their processes of troubleshooting and learning. For I believe that if we all add our expertise, we can learn from "Real Life", and not just from labs. Good work and good learning and growth for everyone! Greetings Jakson Medina That's a lot of MX64s. ISP/end users?

BHC_RESORTS · ‎Aug 29 2017

@Shawtech wrote: What would be the suggested max mounting height for an MV71? I have an request to install security cameras on the roof of a building that is 40ft tall to capture video for the parking lot. We have a camera mounted on top of a 5 story building: Parking Lot

BHC_RESORTS · ‎Aug 29 2017

@mholzer54 wrote: Anything I need to consider. I want them on the same SSID. Or do I just plug it in to my POE switch and configure it like the other one? Once you order it, you should get a dashboard key (or order number). Add the license to your dashboard, and the device will populate to your inventory. Add it to the appropriate network (if you have more than one), and then it will automatically obtain its settings once plugged in to the switch - so long as you have the SSID set to broadcast to all APs.

BHC_RESORTS · ‎Aug 18 2017

@Mr_IT_Guy wrote: @NFL0NR, don't you think we should also be eligible for the polo 😄 I think I had to buy about $250k worth of equipment before I got mine!

BHC_RESORTS · ‎Aug 18 2017

Firmware updates are the only thing that somewhat scares me on Meraki products. Not having your trusty serial connection to xmodem over an update in case it didn't work...99% of the time, they go smoothly, but when they don't...

BHC_RESORTS · ‎Aug 16 2017

Strange. Well, the beta firmware is 9.26, and while it isn't always a great idea to run beta in a production environment...the stable track is pretty far behind at this point, so I'd weigh your options. I skimmed through the release notes, and I didn't see this specific issue mentioned, but there are a TON of stability and bug fixes, so you never know. We run two MS2208p, and are on 9.26 with no issues yet. Small sample size, I know.

BHC_RESORTS · ‎Aug 16 2017

@bholmes12 wrote: I have 3 MS350 stacks, 6 switches in each stack, running on 8.10 software. All stacks have been up and running without issue for the past month or so. No changes have been made on the Meraki switches or the Cisco Nexus 9k's that are upstream. This morning within an hour all 3 stacks had switches that removed themselves from the stack and stopped forwarding traffic. Stack 1 - 1 switch disappeared from the stack and stopped forwarding traffic - Did not come online until after a reboot. Uplink port was not on this switch. Stack 2 - 1 switch disappeared from the stack and stopped forwarding traffic - Did not come online until after a reboot. Uplink port was not on this switch. Stack 3 - 5 of the switches disappeared from the stack - 1 of the uplinks was on one of the switches that disappeared from the stack. After rebooting the switch with the uplink the 5 switches rejoined the stack. 1 switch in this stack stayed online, that switch has an uplink to the core. It seems really strange that 3 stacks had the same issue within an hour, Meraki support suggested we hit a bug (8.10) and have requested I upgrade to 9.19. Has anyone else been having stacking issues? I typically put in Cisco 4500's or 3850's and these are my first 3 MS350 stack closets. This obviously isn't giving me a very warm and fuzzy feeling to have a failure like this after a month or so. Curious what other users experiences have been when using MS350 stacks ??? The MS line is the one product we don't run in our environments, so my advice is more theoretical than practical I'm afraid. Did the logs show anything interesting regarding the stacking? Also to be clear, we are talking about physical stacking here, not virtual stacking, correct? Normally I would blame the upstream Nexus 9ks, as those have more bugs than a Brazilian jungle, but since some of the stacks don't uplink to it, i'm not so sure.

BHC_RESORTS · ‎Aug 15 2017

@TheMerakiGuy wrote: Meraki uses LLDP for automatic discovery of connected devices. https://documentation.meraki.com/zGeneral_Administration/Other_Topics/LLDP_Support_on_Cisco_Meraki_Products LLDP is enabled by default on all Meraki devices with varying degrees of support. Keep in mind that if you are not a full stack customer you will likely have to enable and or configure LLDP your other network devices. Note you can always suggest a new device type to Meraki if you find that the automatic discovery is incorrect. Select the client in question under Network-wide > Clients Click on the gray flag to the right of the existing device type Enter the correct device type and click "Save" This will not update the device type in your dashboard immediately but I have had success using this feature in the past. Providing accurate feedback to Meraki should help them to identify and resolve any potential problems. I'm pretty sure it uses more than LLDP for device identification. The majority of connected devices do not support LLDP, which is more designed for network infrastructure hardware. My guess would be it uses a combination of LLDP, SNMP, WMI, and MAC vendor lookup. Flagging the device type as inaccurate has never resulted in any changes for me. We have like 100 Vizio smart TVs that show up as Axis cameras, and I've flagged a ton of them. Since they all have the same MAC Vendor OUI, it should be a pretty easy fix. For this example, looking up the MAC returns "Vizio, INC". Sure, it doesn't identify it as a TV, but at least it gets the right manufacturer.

BHC_RESORTS · ‎Aug 15 2017

@Mr_IT_Guy wrote: @CarolineS does Meraki have any plans for CMNOs to eventually be allowed to become CMNA or a Master? I too have asked about this, with some of the Meraki marketing management. But the more Meraki employees we pester about it, the better. Judging from some of the deployments I've seen mentioned here, a lot of the "end-users" likely make much more significant purchases than some of the partners who may just be resellers or VARs. It would be nice to be recognized as well with advanced training opportunities.

BHC_RESORTS · ‎Aug 14 2017

@george26 wrote: Would anyone use a z1 on a connection serving guest wifi for 10-15 users? 2 options for internet speeds are 16/3 or 50/10, which customer will probably go with the lesser. The Z1 is designed as a telecommuter device. Consequently, it has a much lower CPU than the normal MX line. It also doesn't have a lot of the more advanced features that the MX line has. 16/3 is pretty rough for even 1 user. What is the purpose of the guest WiFi? If it is just in a bar or restaurant or something, it is likely people won't use it much for things other than checking in to Facebook or looking at directions. If it is in an environment like a hotel or something else where people are going to be for a while, that won't do. Traffic shaping isn't really granular on the Z1. I'd recommend an MX64 plus an AP. The MX64W or the MX65W isn't as robust on the WiFi. Remember, MX64s and an AP (model varies now I hear) are available via webinars for qualified attendees. I'd check that out!

About BHC_RESORTS

BHC_RESORTS

Community Record

Badges