Remote working for a secure and collaborative future: Meraki MR Teleworker

The interruption of our daily work life that COVID has caused will not go forgotten. Increased pressure from employees, stakeholders, and investors will change the industry’s perception of what productive and innovative work environments can be. With the realization that the more we work from home, the more likely we will continue to work from home beginning to set in. Organizations are looking for solutions. 

There are numerous solutions to provide a productive remote working environment. Traditional client and client-less VPNs, VDI solutions like Citrix XenApp/Desktop come to mind. These solutions have worked for years, and most certainly still do. Often this requires some infrastructure to support it. 

If you were an organization fortunate enough to have the infrastructure in place pre-COVID, transitioning to remote work was probably a pure uplift for you. You may have needed to scramble to get more VPN licenses or lease more bandwidth to meet capacity.

Unfortunately, some organizations don’t have a work from home policy or even a contingency plan, let alone the infrastructure to support remote workers.

The MR Teleworker VPN is a solution that extends the corporate LAN to employees at remote sites with Meraki AP’s. It may be the path of least resistance for those organizations that have temporarily or permanently shifted to remote working.

A Meraki AP at a remote site or your home establishes a layer two connection using an IPSec-encrypted UDP tunnel back to the corporate LAN. The L2 tunnels are built on a per SSID basis and terminate at a headquarters on a Meraki MX security appliance.  

An access point would typically require a switch with PoE capabilities to power the Meraki AP, but that’s not usually something an average worker has. So for my setup, I’m using a PoE injector with a Meraki Wifi6 MR36 access point plugged into a LAN port on my router.  

Optionally we could take this one step further and provide split tunneling. Let’s say you wanted to offer a personal SSID for your remote workers. You could enable split tunneling, which would prevent the traffic from hairpinning to the headquarters before egressing to the internet. 

Again, the VPN tunnels are built on a per SSID basis, so you would create a new SSID for personal use and change the VPN tunnel type. Three VPN rules will be enabled by default. You might add more specific rules above the last statement, the default rule, if you required them. 

Agility will be a new competitive advantage in a post COVID world. It will require companies to reimagine where their applications live, where their workers work, and how to secure all of it while meeting their customer’s needs. The MR teleworker VPN is only one example of many that will meet the requirements for remote workers.

Mike

Bringing wireless to the Cloud

It’s been a bit busy as of late. The holiday seasons are just around the corner, and wireless is in the cloud.

The word “Cloud” is such a hot word right now. Everything these days is starting to move to the ‘cloud’.  Most vendor marketing folks end with something along the lines of “..AND rest assure, your data will be in the “Cloud”…Then everyone soils at the thought of their data being in the cloud with; with no inclination, no questions on how their data will get there, the security of their data, or, or if their current infrastructure can support it! GAH!

In any case, yes wireless is now being offered in the Cloud, and at the for front of this is Meraki. Meraki was founded in 2006 by MIT students and was acquired by Cisco in 2012. Since then they have been offering wireless hardware and services to mainly enterprise entities. They provide a suit of hardware and services ranging from APs, switches, firewalls, phones and more.  I find their hardware to be modern, it kind of reminds me of Apple; sleek, minimalist design and easy to install. They have an intuitive management dashboard that provides administration and configuration of your devices. You can even leverage the analytical data captured by APs for targeted advertisement to your customers.

meraki

Want to learn more about Meraki? Want a free AP? For a short time, Meraki is giving away a free AP if you attend one of their hosted webinars. If you’re lucky, you may even get a switch! Here’s the link https://meraki.cisco.com/freeap

Mike

Cisco WLC 8510 MIC bug

Welcome one, welcome all to the second blog. Today’s discussion will be on a bug that was found in a recent software upgrade to a  8510 wireless controller. Let’s begin.

 

If you are one to stay on the straight and narrow when it comes to downloading and installing Cisco software, then I applaud you. We have something in common. By the “straight and narrow” I mean, sticking to ‘Star’d’ releases. You know, the ones with the star just to the right of the software version? The Cisco’s “suggested release” based on software quality, stability and whatever else they deem star worthy. And the ones who are daring to test the waters of the non-star’d software versions. Eh, I guess I like you too.

starded

It’s like dealing with the Salton sea when it comes to Cisco software releases. I mean come on! Feed the sea to much water and you begin to waste water. Feed the sea too little water, and the sea begins to evaporate leaving toxic sand behind. Before you know it, you’ve got asthma and not enough water to take a shower! Anyways I digress. It’s a double edge sword to say the least.

We have been using manufacturer installed certificate (MIC) for some time now. Basically just to contain unauthorized Cisco APs from joining our controllers. And up until now we have been utilizing the web interface to add the mac address of the AP to our AP policies. This changed after upgrading our controller to software version 8.0.133. After the upgrade, you can’t add mac address via the web interface. You get this nice little message.

ssc

SSC isn’t checked! So what’s your issue man!

Through Cisco’s bug search tool this little guy came up.

bug

The workaround was valid. It worked just fine through the cli.

In all, It really isn’t that big of a deal. It was something that I felt interesting enough to post about. The bug number is in the screen shot, but here it is if you missed it. CSCuz60224

Mike

Cisco Universal AP

An interesting find at one of my customers sites this week…

Cisco has a universal AP product line that address the worldwide regulatory compliance requirements for APs. It allows an administrator to dynamically set the regulatory domain in which the AP will be operating. Regulatory domains define operational standards like available channels, power levels, etc.

This differs from the Cisco Aironet Access Point models which have a fixed regulatory domain. Meaning they are most likely purchase and shipped within your country and come preconfigured to operate and comply with your countries regulatory domain.

Cisco’s Universal APs require priming the AP with the regulatory domain and country for proper use.  This process is actually really easy and kinda fun if you have never done it before. It does require a smartphone with WiFi and GPS capabilities however and Cisco’s AirProvision app.

In my customers case, all of their AIR-AP2702I-UXK9 APs were deployed without being primed. I recognized there was an issue when the APs LED lights were cycling between Red-Green-Off. Jumping into the controller under the ‘Advanced’ tab of the APs I was able to confirm that the Country Code was ‘UX’ and Universal Prime Status was ‘Unprimed’.

Now this find was by complete coincidence because I was on site for a completely difference issue. The customer thought the LED lights were normal and the customer was using the wireless so they didn’t see an issue. The problem went unknown because of this. But, by default an unprimed AP will broadcast its SSIDs only on the 2.4 GHz band, at a lower power level that is acceptable in all regulatory domains and will completely ignore the 5 GHz band until the AP is primed. So your AP is quite trash at this point.

In any case, through the use of the Cisco link below, I was able to prime all of my customers APs by manually priming one of them then turning CDP on it’s radios and CDP on the neighboring APs radios. Through the use of  NDP messages sourced from the manually primed AP, it was able to propagate it’s regulatory domain to it’s neighboring APs.

After you are done you can view the primed status of your APs. The first manually primed AP status will look like this.

The neighboring APs primed status will look like this.

ndp_primed

http://www.cisco.com/c/en/us/td/docs/wireless/access_point/ux-ap/guide/uxap-mobapp-g.html

Mike