Organizations across industries are eager to build their Wireless WAN infrastructure on the Meraki platform and some of them already have a head start with our new product line – MG Cellular Gateway. MG provides a solution for optimal cellular signal strength. It gives our customers the flexibility of pairing MG with any Meraki or Cisco ISR/vEdge router or 3rd party router to provide another uplink for SD-WAN, or as a failover or primary link.
MG was only launched a couple of months ago and we’re already releasing new features. There is no better way to see these features in action than to try it out for yourself.
Quick network diagnosis
We’re always seeking to provide capabilities that truly add value to our customer’s business. For cellular troubleshooting, customers have frequently told us how challenging it can get without any visibility into the signal characteristics at their site. This lack of control leads to them taking a hit on business functions that rely on cellular signals.
MG users can now take advantage of this data within the Meraki platform to quickly diagnose what’s affecting cellular connectivity, or what led to performance degradation, through historical stats— signal strength, latency, and loss—that are visual and easy to interpret. By knowing how cellular connectivity is at certain sites at any given time, it’s simple to get to the root cause of network issues. Easy monitoring of live data along with the signal level, signal quality, and connectivity data could potentially save hours of troubleshooting.
It gets even better with an API-driven architecture. MG can be managed completely through APIs, giving customers the flexibility of custom reporting and integrations that they need. Stay tuned for more updates!
How to access
From your Meraki dashboard, go to Monitor->Cellular gateways; select the MG for which you’d like to get the health data, and then go to Uplink from the menu bar. Scroll below to view the historical and connectivity data as far as 30 days in the past.
Typically, when we write these MV-related blog posts, we love to highlight the challenges that a particular feature will help you overcome, or the frustration that a new solution will help ease. Other times, we want to be a little bit more flashy. This is one of those times.
With the recent launch of Cisco Meraki’s second generation of MV cameras, customers can now take advantage of three zooming features on both their indoor and outdoor cameras: optical zoom (available on MV22 and MV72 only), sensor crop, and digital zoom. While each is powerful in isolation, when combined, these three features allow you to achieve truly dramatic levels of magnification on your video feed while maintaining extremely high video quality.
Just how dramatic is the zoom? Let’s take a look below.
What you can accomplish today with MV
The following images show the progression of an image when each zoom option is applied. The first photo shows the video feed from an MV72 outdoor camera with no zoom applied. You can see something is on the table in the far corner of the patio, but not much else.
Screenshot from MV72 video feed with no zooming applied
The next image shows a maxed out optical zoom, focused on the table area. We can start to see something take shape, and that shape looks suspiciously like a gnome.
Screenshot from MV72 with optical zoom applied
In the next image, we use sensor crop to focus in on an even smaller area. Sensor crop, like optical zoom, is lossless zoom, meaning there is no loss of detail or stretching of pixels. Things are starting to look a little clearer, and we can definitely tell this is one of those mischievous Meraki gnomes.
Screenshot from MV72 with optical zoom and sensor crop
For an extra bit of fun, let’s see what happens when we use digital zoom. Maybe we’ll be able to identify which Meraki gnome it is. Can you guess?
In-dashboard digital zoom of the MV Gnome
With digital zoom, now you can see that this gnome is sitting on what looks like a security camera. It’s the MV gnome! (Did you expect any different?)
Digital zoom can be used on live and historical footage. Keep in mind, though, that that sensor crop and optical zoom only apply to footage that was recorded after you applied the settings to the camera. You cannot apply sensor crop and optical zoom on historical footage. So, the dramatic level of zoom illustrated above is only possible if optical zoom and sensor crop were already applied before using digital zoom.
If configured properly, your MV cameras can truly can give you (gnome) portraits from pixels.
Early in 2012, a startup company beginning to make waves in the networking industry introduced a new feature for their line of access points. This startup was called Meraki, and the feature launched was Air Marshal. At the time, the functionality satisfied the security requirements of a typical wireless network: automatic containment of rogue APs seen on the LAN, keyword containment of SSIDs, scheduled Air Marshal scanning, and the ability to configure additional APs as Air Marshal sensors for round-the-clock protection.
With the introduction of the MR34 in 2013, Cisco Meraki introduced the dedicated scanning radio and this took the Wi-Fi industry by storm! No longer would admins have to choose between performance or security. With the dedicated scanning radio, the MR was now capable of servicing clients while simultaneously listening to the entire RF spectrum, protecting clients from malicious rogue APs.
The constant surveillance of wireless networks continues to be important, but recent trends in cybersecurity and the growth of Internet of Things (IoT) requires added flexibility when it comes to securing wireless networks.
No, James Spader won’t be lending his hand to protect your wireless network. But, much like his character on the popular TV show, Air Marshal will work to eliminate (or contain) all SSIDs found on “the list.” TV shows aside, Air Marshal traditionally made it simple to automate containment of rogue SSIDs that are seen on the LAN, or contain SSIDs that matched a keyword.
However, some environments may have a network comprised of multiple vendors, or may be a part of a collaboration workspace where numerous companies may feature their own WLANs, connecting to the same wired network infrastructure. In this instance, automatic containment of rogues seen on LAN won’t work, as the non-Meraki APs would cease to function for their clients.
But administrators no longer have to forfeit their security capabilities. With Air Marshal’s new SSID Blacklist table, rogue SSIDs won’t be automatically contained, but security rules can be configured to match on a variety of conditions allowing for an accessible network to be locked down with finely tuned security controls.
Security rules may match on four different conditions: exact matches, MAC address matches, keyword matches, and wildcard matches. The rules defined in the SSID blacklist table will match against SSIDs that are seen on LAN, as well as Other SSIDs that are “heard” by the Meraki APs but are not found on the LAN. Any matches will result in the MRs within the vicinity of the rogue or other SSID to actively contain the SSID, rendering the offending SSID useless for clients who wish to connect. Exact matches will match on the SSID seen (whether the SSID is seen on the LAN or not), while keyword rules will ignore surrounding characters and match on just the keyword specified. BSSIDs (MAC addresses used to identify a Wi-Fi network) can be matched against if specific radios (2.4 GHz or 5 GHz, for example) that are broadcasting need to be contained.
The wildcard match provides the greatest amount of flexibility. Wildcards can be used to substitute a string of characters with a single *, or a single character with a single ?. For example, an SSID Blacklist wildcard rule may match the following text: ‘*12345’. If the MR detects an SSID broadcasting ‘Guest-12345’, then that SSID will be contained. If the rule is configured to match on ‘Guest-12?45’ and the MR detects an SSID broadcasting ‘Guest-12345’ or ‘Guest-12Z45’, then that SSID will also be contained.
Merely containing the SSID isn’t enough, though. Administrators often want to be cognizant of the rogue SSIDs that are being detected and secured by their MR access points. As such, if the administrator has configured email alerts or syslog in their Meraki Dashboard, they’ll stay apprised of their security rules in action.
Good News, You’re on the (White)List
Seemingly every other day, a new company is featured in the media as being the latest victim of a cybersecurity attack. Wireless networks are often considered the edge of the network infrastructure, the first line of defense in many cases. As a result, many administrators and security teams alike want to automatically contain rogue SSIDs seen on the LAN. While this grants the highest level of security enforcement, interoperability issues may arise when factoring in how often wireless display adapters and IoT devices connect to the network.
In the modern enterprise, HDMI cables are being replaced with Wi-Fi Direct adapters to make screen sharing and video streaming simple and intuitive. In the majority of instances, these Wi-Fi Direct devices (an adapter and client device, such as a PC, printer or remote) will often communicate on their own, freshly created wireless network. Sounds easy enough… except for one slight issue. This isn’t an SSID that’s broadcast by your MR access points, and in no time at all, deauthentication frames are being sent over the air in an effort to protect your devices from the suspected intruder. While the security team is rejoicing, the network administrator is still working to find a way to whitelist these devices so that security can be maintained with just enough flexibility for day-to-day employee operations. Enter the SSID Whitelist table:
The newly familiar faces are all here when it comes to the way that SSIDs can be matched to whitelist from containment. Exact matches, keyword, MAC, and wildcard can all be used. However, unlike the SSID Blacklist table, the whitelist table will not send email alerts or syslog messages when SSIDs are matched.
Alert, but Don’t Touch
There may be instances where administrators wish to be alerted when certain SSIDs are “seen” on the LAN or “heard” in the air, without taking any specific blacklist or whitelist actions. Using the same match conditions available for the SSID Blacklist and SSID Whitelist tables, alerting security rules may also be configured. These alerts will be sent via email and syslog alerts, if configured.
In With the New
Security has been at the forefront of Meraki since the introduction of Air Marshal in 2012. With the latest enhancements made to Air Marshal, new security rules can be configured to match on a variety of conditions, enabling administrators to implement granular security policies that are flexible for the modern workplace. These new Air Marshal features encompass the rapid innovation made possible by the Meraki dashboard. The new Air Marshal enhancements are available free of charge for existing MR customers as part of a seamless Dashboard update. For the SSID whitelist and SSID alerting functionality, the MR network must be set to MR25.9 firmware or higher. Visit our documentation for more information on configuring Air Marshal.
Chris Gasaway, Director of Technology at Rockwall ISD, joined us on January 29th to share his experiences creating a secure network to support the growing trend of BYOD with students and faculty/staff. Rockwall ISD is an expanding school district just outside of Dallas, Texas with 2 high schools, 3 middle schools, and 12 elementary schools.
The district is comprised of families who are extremely mobile device friendly and expect the best in technology for their children. While the district has over 6,000 computers and over 4,000 iPads available for use in the schools, Chris wanted an environment where students could bring their own personal devices and connect to the school’s network.
Taking advantage of the numerous SSIDs, Chris created custom experiences depending on user type, shaping traffic and setting firewall rules as needed. In a few short mouse clicks, not only was the network secure and CIPA-compliant, but he can also make changes as needed based on new requirements or challenges. Chris now has deep, granular visibility into the devices, users, and applications on his network, with the ability to troubleshoot on the fly.
Check out the video from the webinar – see how Chris created a BYOD revolution at Rockwall ISD, encouraging the explosion of personal devices within the school system, while still maintaining control and network security.
We’re excited to announce that Cisco has announced its intent to acquire Meraki. After close, we’ll become Cisco’s new Cloud Networking Group. Our HQ will stay here in San Francisco, and the Meraki team will continue to focus on customer experience.
We’ve put together an FAQ for our customers and posted our CEO Sanjit’s letter to employees. The press release can be found here. We’re looking forward to bringing our innovative cloud-based networking technology and business model to even more customers and partners.
Apple announced during its recent unveiling of the iPad mini that almost every single Fortune 500 company had deployed the iPad in a business application or is testing iPads at the moment — that is nothing short of amazing for a device that was launched less than three years ago!
Apple’s much anticipated iOS 6 release packs a number of API enhancements for mobile device management to support the growing number of businesses that are deploying iPads, iPhones, and iPods for various applications.
We’ve integrated many of the new MDM features in iOS 6 into Systems Manager, our free solution for mobile device management. Systems Manager users have access to these new features without having to install any new software or make any changes — it’s all right there in the Systems Manager dashboard!
Our new iOS 6 MDM features include:
Single App mode under Guided Access
Ability to disable iMessage
Passbook, Game Center, iBookstore, and shared Photo Stream blocking
Single App mode, also referred to as “kiosk” mode, locks the iOS device to a single app and disables the home button. A few scenarios include:
Retailers: Enhance the customer experience by creating a mobile point of sale (mPOS) terminal, without worrying about the iPad being used for any other purposes.
Hospitality: Enter the digital concierge! Hotels are setting up iPads in their lobbies and guest rooms, allowing guests to check in and out, order room service, and have various services literally at their fingertips. All that’s needed is an iPad — or iPad mini — set up in kiosk mode.
Education: Schools are already using iPads for various learning initiatives, and they can now be locked to a single app so students aren’t distracted.
With iOS 6, disabling iMessage is a welcome addition to the security and compliance groups in highly regulated industries that need to concern themselves with archiving all communication and information exchanges for e-discovery.
Note that for some of these features, Apple requires the device to be placed in supervised mode by Apple Configurator — but not to worry, Meraki Systems Manager also integrates with Apple Configurator, allowing supervised devices to be managed via the Meraki dashboard.
If you haven’t given Meraki’s Systems Manager a try yet, go ahead and give it a try – lots of awesomeness awaits you!
At Meraki, we love getting our gear into people’s hands. We think we make a pretty awesome product and once people get a taste of how easy to use Meraki is, they become our biggest fans.
Our latest greatest idea is to get our gear into the offices of the hottest, most promising startups through our Meraki Startup Kit – a complete standalone set of networking hardware: two of our highest performance wireless access points, a high-throughput security appliance, and a 24 port switch with Power-over-Ethernet. With a value of over $15,000 – we have a limited number of Meraki Startup Kits, but they are entirely free and include 5 year licenses for qualifying startups.
The Meraki Startup Kit is intended to give small companies a helping hand with their network infrastructure and a way for us to share our success with the next generation of disruptive startups.
As part of our beta release, two startups have already received their Meraki Startup Kits and are enjoying the ease of use with Meraki’s dashboard management.
San Francisco-based Copious – “a social marketplace to buy and sell the things you love” – was the first company to receive a Meraki Startup Kit. With 17 employees and a recent round of Series A funding, Copious was outgrowing its existing networking setup, so getting the opportunity to implement a Meraki network for free was perfectly timed.
For vline, a cloud video conferencing platform for developers, the Meraki Startup Kit will provide a solid office network foundation as the company develops its tools and platform for a wider public release. Ben Strong, vline’s CEO, commented that “Meraki access points are great for video conferencing. Much better than all the other ones we’ve tried.” As vline grows into its Palo Alto office, the Meraki network is an ideal networking solution to support the team.
Today we’re excited to open up the applications to the greater startup community. Meraki hardware is high quality, easy to set up, and low maintenance – the perfect infrastructure for startups relying on rock-solid Internet connections to develop, converse, and deploy in the cloud.
To see if your company would be a good fit for our program, take a look at the requirements and fill out the application here: www.meraki.com/startupkit.
A virtual private network, or VPN, is a connection established between two peers such that each can behave as if they are on the same subnet. VPN is very commonly used to connect remote workers to a corporate network so they can access email, files, and network resources when away from headquarters where these resources typically reside.
Figure 1: Teleworker VPN extends the corporate network to the branch or home office
Road warriors rely heavily on VPN and depend on its security and reliability. Luckily for them, they don’t have to deal with the complexity of configuring and managing VPN. Unfortunately, VPN deployment is no easy task for any IT administrator. Until now, that is. Meraki’s new Teleworker VPN makes configuration and deployment painless, and it even eliminates some previously required hardware components entirely.
This is how easy it is to get VPN up and running:
1) Download the VPN virtual concentrator from the dashboard and install it in a VMware virtual machine
Figure 2: download VM image for VPN concentrator
2) Click “Enable VPN” on the Network-wide settings page
Figure 3: tunnel AP traffic back to VPN concentrator with one click
3) That’s it! Any access point on this network will now have a VPN connection back to the corporate network, and it will be completely transparent to the user.
There is no client-side software to install, no VPN concentrator box to manage at headquarters, no messy provisioning on each client machine. The remote worker connects to the Meraki access point and sees all the network resources that are available when physically located at headquarters.
Meraki’s cloud-based architecture makes this all possible. Access points automatically traverse NAT and firewall settings using a technique called hole punching. This allows the APs to find and connect to the cloud controller for configuration and establish the secure link to the corporate network for VPN traffic. There is no AP provisioning needed from the IT administrator, and the APs receive and install the correct configuration for their network automatically.
Some background: IPsec
Let’s take a look at just a bit of what happens behind the scenes when using a VPN link via IPsec.
IPsec is a group of protocols that provides mutual authentication and encryption between trusted peers so that an end-to-end connection can be secured. It operates at the IP layer, meaning any application that uses IP can be protected by IPsec, and applications do not have to be redesigned or adapted to be secured.
VPN has many, many options and controls. Some of them handle authentication and identity functions, while others handle encryption and securing of data. Instead of exhaustively going over each, it’s best to first gain an understanding of a commonly implemented form of VPN. A simple way to understand what happens in VPN via IPsec is to look at the packets in encapsulating security payload (ESP), a common type of encryption and authentication. Tunnel mode of ESP is used when connecting a remote user to a network or when connecting two routers that link sites.
Peeling the onion: packets within packets
Consider first a normal, unsecured IP packet. The major structural parts of the packet are the header and the payload. The header has many components, but for this discussion, the most interesting one is the protocol field. This field describes the protocol of the information contained in the payload. Very often the payload contains a TCP datagram, so the IP header will indicate protocol 6, for TCP.
The IP payload then contains the TCP datagram: a TCP header and TCP payload. This is the same TCP/IP packet type that is so widely used over the Internet today.
Figure 4: original, unprotected packet
This method provides no security for the communicating parties. An eavesdropper could view packets on the wire and listen to the conversation between a source and destination. Clearly, this is not suitable for private communications where sensitive data needs to be exchanged. That’s where VPN comes in.
In a configuration providing a VPN over IPsec using ESP, IPsec takes an IP packet, secures it completely (including IP header and payload), and wraps it in a new payload format, called encapsulated security payload. It attaches a new IP header and modifies it to point to a payload (ESP), instead of the original unprotected IP protocol payload. The original IP packet, including header and payload, become the new payload data contents of the encapsulated security payload. ESP also includes a trailer, after the payload, that includes some padding and points to the payload type (in this case, TCP). Authentication is optional with ESP, but highly recommended. When using authentication, a few more bits of information are added to the ESP trailer.
Figure 5: IPsec encrypts and protects the original packet
That summarizes the packet structure when using IPsec with ESP. But one might wonder how, exactly, is the information actually protected? The data of interest, now part of the encapsulated security payload, is still inside the packet. How is it protected from prying eyes? To find out, we need to peel another layer of the VPN onion.
Using encryption and authentication requires that each peer verify the identity of the other and have some way to de-encrypt the desired data. This means they must have knowledge of secret keys, algorithms used, and protocols used (for example, AH or ESP). Security associations are simply parameters that describe the algorithms, secrets, and keys used in a one-way connection. Naturally, most connections are two-way, so a pair of security associations is required in the case of IPsec with ESP. These parameters are stored in the security associations database (SADB). The SADB keeps track of a large number of parameters, including the ESP encryption secret key, the ESP encryption algorithm, and the ESP authentication enabled flag.
If data is protected using encryption and authentication, and if encryption/decryption is performed using secrets, it follows that knowledge of the secrets is a very critical requirement for ESP to function properly. The transfer of knowledge of the secrets must be done in a secure way so that unwanted parties do not learn it. There are several ways to do this, ranging from manual installation to key management protocols. Key management protocols allow for the secure exchange of keys (and other security association parameters) without the need for manual installation, making them suitable for large-scale deployment and configuration.
Choose your encryption algorithm
ESP itself does not specify the algorithm to use for encryption, but instead lists several from which to choose. A very commonly used algorithm is AES-CBC: advanced encryption standard with cipher block chaining (mode). AES was selected by the USA’s National Institute of Standards and Technology (NIST) as the government’s dedicated encryption cipher, with the expectation that it protects unclassified, sensitive information at least until the next century. AES is commonly used with 128-bit or 256-bit key sizes, making attacks extremely processing intensive and thus completely impractical. Another common algorithm is TripleDES, or 3DES, which is based on the data encryption standard (DES). DES was found to have weak keys, but TripleDES gets around this by processing each data bit block three times in a chained fashion.
Even if information is encrypted, it’s still necessary for each peer to establish and verify the identity of the other party. When using ESP with authentication, as is recommended, a commonly used authentication algorithm is HMAC-SHA1-96: hashed message authentication code with secure hash algorithm 1, using a 96 bit-long authenticator, and operating on 64-byte sized blocks of data. It ensures the packet authenticity and that it cannot be altered while in transit.
Peeling even more layers
There are many more details that are involved in making a VPN connection work properly and securely, but they are out of scope for this article. The key exchange methods and protocols, for example, can provide protection from attacks and can even protect future keys from being stolen by unauthorized parties holding a current key. Another topic ripe for illustration is how peers initiate communication in the first place – the discovery process.
This article discusses one type of VPN, remote access. Site-to-site VPN is another type of connection and is used to connect two fixed locations between gateway points, replacing leased-line WAN connections. Meraki’s MX router has integrated site-to-site VPN capability and is as easy to turn on as the Teleworker VPN shown here. More information is on our website at http://meraki.com/products_services/vpn/.
In January, Meraki introduced the industry’s first cloud-managed routers, the Meraki MX50 and MX70. Through Meraki’s Cloud Controller, they bring valuable insight and control into wired networks, making it easy for administrators to monitor and fine tune the network, ensure optimal performance, and solve client or network issues. (more…)
Amidst all the excitement around the release of our MX series cloud managed routers, we’ve been hard at work building new wireless technologies. Today, we are very excited to announce three new additions to our wireless product portfolio that provide greater capacity, increased security and broader reach for enterprise wireless LANs:
The Meraki MR24 ultra-high performance wireless access point, the first enterprise class AP to feature 3-stream,
3×3 MIMO technology.
Meraki NAC, the industry’s first network access control solution built in to a wireless LAN
Meraki Teleworker VPN, which provides secure remote access to the corporate network for wired and wireless clients like VoIP phones and iPads
The Meraki MR24 is the first enterprise class AP to feature 3-stream, 3×3 MIMO. This technology allows both of the MR24’s radios to use 3 data streams at once, for a total of 6 streams.
Independent testing of the MR24 by engineers at the Tolly Group saw speeds of over 240 Mbit/s – almost 2.5x the maximum speed of Fast Ethernet! Even at a range of 150 feet, testers recorded nearly 200 Mbit/s throughput.
We’re extremely excited to add this ultra-high performance access point to our wireless LAN family. We hope that it will be a valuable tool to our customers as they meet growing wireless capacity requirements.
The MR24 is available for immediate order at a list price of $1199.
Meraki NAC prevents clients without antivirus protection from accessing your network, reducing the threat of viruses and worms in increasingly open enterprise environments. Like our Traffic Shaper, Meraki NAC is a solution that previously would require the integration of a 3rd party NAC – with hardware, client software, VLAN configuration, AD integration etc.
Our NAC is the first NAC solution to be built directly into a wireless LAN. Configuration is done with just two clicks. Meraki NAC adds additional protection on top of existing features like our stateful policy firewall and guest isolation. Meraki NAC is included with our Enterprise Cloud Controller license, and will be rolled out to existing customers at no cost starting today. Enjoy!
Meraki Teleworker VPN
Meraki Teleworker VPN allows users to securely access their corporate network, including file servers, VoIP phone systems, and internal applications, from any Internet-connected Meraki AP. This AP establishes a secure tunnel back to headquarters – using our Cloud Controller to handle complexities like NAT traversal, key negotiation, etc. Teleworker VPN lets you extend the full office experience to remote workers: plug in a VoIP phone and get a dial tone or wirelessly access your private cloud from an iPad. Our teleworker solution enforces security policies like 802.1x, traffic shaping, and our new NAC, right at the edge, so your corporate network is well protected. Teleworker VPN is available on all Meraki enterprise APs at no additional charge (no VPN license!). Rollout to existing customers begins today. Learn more about our VPN solution, including both our new Teleworker VPN and site to site VPN with our MX routers.
We’re very excited about all of these new products. We’ll be following up with detailed posts about each of them in the coming weeks. In the mean time if you have any feedback let us know!