Meraki Wireless Concentrator – Tips and Tricks

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.



One thought on “Meraki Wireless Concentrator – Tips and Tricks

  1. Cheers for the article, very informative. I have a meraki MX in NAT mode while still concentrating my AP’s internally for tunnelled guest internet access. I was told by cisco pre-sales this could be done (back in 2015 before, i think that warning was published on the meraki site) but found the same issues as you.
    I did however find a way to terminate vpn’s to the lan port. To do it you need to add an internal route to the “Public IP” of the MX but push it to the LAN port IP address of the MX LAN port. the meraki, then will terminate the VPN traffic to the LAN port (it likely routes through itself internally to the wan port). so effectively you can terminate the vpn on the LAN while the static routes back to the LAN ranges (the ones the AP sit on) send the traffic back to the AP correctly.

    problems i’ve experienced on this are that the application statistics are messed up. all i see coming up is the AP’s IP addresses in the reports (not the real client IP’s), so i can not identify the abuser of the internet (i.e. bit torrent)… which is bloody annoying. it also reports a load of UDP traffic which i am guessing is the VPN tunnel from each of the AP’s itself (probably due to the NAT mode routing config i have the mx doesnt differentiate the tunnel from the real traffic.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s