I have deployed the Meraki MX series many times, along with the MR access points.    One of the most popular articles I have written to date was Meraki Guest Access – The Better way an article about another way to deploy guest access in the network with fine grained policies across perhaps multiple networks.

One of my recent deployments I had a customer who wanted to tunnel all guest traffic back to an MX – similar to how his existing legacy wireless system does it, so that he could send that traffic back to a dedicated connection OUTSIDE the firewall.   Basically the idea is that we want guest traffic to never get anywhere near the corporate network.     We also had multiple sites in play across a L3 WAN, so simple VLAN segregation would not work. (yes yes, I know there are other ways to do it, but we are keeping it simple here)

Meraki MR has the ability to L3 or VPN tunnel traffic back to an MX – but be aware of the following warning and important design considerations.

This configuration is designed for use with an MX in passthrough/concentrator mode, tunneling to an MX in NAT mode is not supported.

This warning comes from the Meraki web site, right here where it discusses the various modes in the MR.      The problem is – it will not stop you from trying, and even in NAT mode, the “Wireless Concentrator” options still show up in the MX config screens.    It even tries to work if you configure it, and in some cases it actually functions – but – not supported.

Important MR L3 Tunnel Caviats

    1)    Only Pass through / Concentrator mode is supported

As mentioned above, even though it might appear to let you configure it – and while I have had it working at clients before, it is not supported.   As a result there are many core MX features that are disabled, for this reason, I would not buy the advanced security license for a dedicated MR concentrator device.   Those features do not really function in this mode if you are using it primarily as a concentrator (they do work if traffic is traversing through the device interface to interface)

    2)    Content Filtering is not supported in passthrough mode

While layer 7 filtering is a component of the wireless access point – web page content filtering by category is an MX function, and in pass through mode the traffic from the MR’s doesn’t really pass through the MX, so the content filter is skipped.   Funny enough URL blacklists do still work, but the categories do not.

    3)    No DHCP

You don’t get a DHCP server in this mode, which means you need some kind of DHCP for your guest users.   Whatever your edge device is or switch could handle this.  DHCP requests are tunnelled back to the MX and broadcast at the MX – so you can have a remote DHCP for this.

    4)    Tunnels can only terminate on the “Internet” interface

If you are trying to do this in NAT mode (Which you shouldn’t be doing)  this will trip you up.   Either way understand that the way it works is that the MR contacts the Meraki Dashboard and reports the public IP it is on, so does the MX, and then the VPN tunnel is created between the two devices using those IP’s as a baseline.  So this traffic is really designed to go to the internet.    You can override this behaviour in case your MX is on the inside of the network (has a private IP on the INTERNET interface), if you go into the MX Wireless concentrator screen you can put an internal IP on the MX and make it take the “inside” route if you want.  Your mileage may vary here.     However if you try to use NAT mode, and force the AP’s to use the “inside” interface of the MX — forget it — that will not work, the VPN process in the MX isn’t listening on the inside interface – only on the outside – again NAT mode is not supported.

    5)    SSID’s with down Tunnels do not transmit

If your MR cannot open a tunnel to the MX – the SSID will NOT transmit.    So keep this in mind, if you do not see the SSID broadcasting out of your access point – that is a real great indicator you have a tunnel problem.

You might need 2 MX Devices

So some might ask “Wait, in some designs I might need 2 x MX devices to acheive what I want to do then, one in pass through to terminate my tunnels, and one at the edge”  — Yes that is correct.   As the MX you use for the tunnel termination cannot do content filtering on that traffic – and it also can not provide DHCP, you will need another device to get involved in this case.    Another MX would be the right solution.   If you are smart the way you deploy the VLAN’s on the second MX, you could create different SSID’s with different security zones and it would be quite easy to manage it all as well.

 

Watch out for hair-pinning

You may run into some hair-pinning issues with this design,  so be careful of your packet flows.   It’s possible that you could end up going out your firewall, back in, and then back out again.     Packet Capture is your friend here.

Use Packet Capture to Confirm

When troubleshooting the tunnel creation on the MR,  take packet captures of the AP, while pressing the “test connectivity” button in the SSID configuration – you should see the MR attempting to bring up a tunnel with the MX – do the same on the MX interface as well to see if there are responses.   Isn’t it great we can take “remote” PCAP’s on this platform.

I hope this provides everyone with some important rules when it comes to this design, and tips on architecture for your next project.