At a recent technology conference and I found myself answering questions on Meraki wireless design with a curious network engineer. His company was in the process of replatforming their corporate wifi to Meraki wireless and he had some questions around segmenting guest access.
Their existing wireless design used a single controller appliance positioned in a data center DMZ zone so guest wireless traffic could be filtered by a firewall (after exiting the controller). This has been a common deployment for adding firewall protection to untrusted wireless networks for almost a decade.
The engineer’s company was now eager to begin refreshing their wireless infrastructure with Meraki MR access points and were planning on replicating the tunneled, DMZ anchor controller design. It’s not a simple setup, so this friendly engineer had some questions around how the “VPN: tunnel data to a concentrator” SSID option worked in cloud-managed model.
While tunneling and encrypting all wireless traffic on a per-SSID basis to a MX mobility controller is certainly a supported deployment method, I first asked why he was looking to replicate his old design. What were the actual requirements? What fundamental problem are we trying to solve?
Short answer: prevent guest wifi clients from accessing internal networks.
Made sense. The tunneled, mobility anchor controller design using an MX appliance would certainly accomplish that but it would also transfer the existing technical debt and unnecessary complexity. With a new set of tools and a modern management console, might there be a better way?
This is an all-too-common conversation I have with talented network designers and architects. Don’t replicate old ideas with new platforms. Old wine in new wineskins.
There are many options to properly segment a specific SSID’s traffic from sensitive networks, but enforcing firewall rules directly on the SSID itself via the Wireless > Firewall & traffic shaping page seemed like a much more elegant solution. Literally a single dropdown. No extra controllers or MX appliances needed, no complex guest DMZ segments on the data center firewalls, fewer data center routes, and no extra network overhead in the form of encapsulation.
Another side effect is a significant reduction in campus and data center LAN traffic. By using the AP’s own firewall engine to prune any internal, RFC1918 destinations none of those packets ever make it to the local switch.
Better all around and radically simpler. That’s a long way of getting to my point:
Keep wireless designs simple. Layer on features like distributed L3 roaming, tunneling, or device-type group policies when it enhances the client experience or is operationally required.
Defaulting to Bridge Mode
Meraki wireless networks can be configured in several different client IP addressing modes, but most companies should start with bridge mode.
Bridge mode drops client traffic for a given SSID directly onto the AP’s local switch port tagged with the appropriate VLAN ID. If you’re familiar with Cisco Aironet wireless, this is functionally similar to FlexConnect.
- Super simple configuration
- Easy to understand client traffic forwarding
- Fast L2 client roaming by default
- No added overhead or encapsulation
That meets over 90% of campus wifi use cases. Avoid the temptation to turn on shiny features.
Let’s take L3 roaming as an example. I see this (admittedly cool) new Dashboard feature enabled on close to half of production wireless networks that have zero need for it. Sounds better than no L3 roaming, right? Is distributed L3 roaming a killer feature? You bet! What percentage of enterprise wireless networks need it?
The Meraki Engineering team created the L3 roaming checkbox as a way to provide a very clever way to deliver L3 client roaming across IP boundaries without the need for any additional on-prem hardware. You can read more about how it works here, but clicking that button adds resource overhead to every AP in the fabric and lights up a host of auxiliary services on each MR.
If you need uninterrupted wifi calling between campus buildings, it can be an essential tool. If your executive team insists on zero packet drops between logical network boundaries like office stairwells then L3 roaming might be the perfect solution.
My point is those are rare and specific use cases. If you don’t have them, why add the additional overhead, tunneling, and operational complexity? Incrementing network dependencies ultimately increases operational time to resolution.
The Meraki Dashboard makes lighting up powerful technologies easy but as the saying goes, “just because you can doesn’t you should”. When designing wireless networks think carefully about what’s needed, start with bridge mode, and adjust as required.
I ran into the same network engineer last week after presenting updates on MX SD-WAN at a local Cisco Connect event. I asked him what design they ended up using for segmented guest services and he responded, “bridge mode with the built-in AP firewall”.
Now they’re in the fun position of finding a home for an extra MX appliance. After the SD-WAN presentation, I think he had some ideas.