Reference architecture for Guest SSID tunneling

pfoster
Comes here often

Reference architecture for Guest SSID tunneling

OK, so I'm new to Meraki and finding that unlike Cisco there really don't seem to be any reference architectures like the Cisco validated designs. Is there such a thing for Meraki?
 
We are replacing a Cisco WLC system that is using an anchor controller to tunnel all guest traffic through the network and release them to the Internet at the DMZ. We want to replicate that design with Meraki. To that end, we purchased pairs (multiple DC's) of MX105's I intend to build as HA pairs in the DC's. Obviously some MR's as well.
 
Corp SSID clients will be released in their local wifi VLAN, and Guest SSID clients should be tunneled to the MX. My questions are many, and I will list some of them here:
 
MX physical connectivity: As I  understand it the MX should be configured in a one-arm VPN concentrator mode. The MX will be located in the DC DMZ behind the edge FW.
 
I know I will need the WAN ports connected and NAT on the edge FW to allow the MX (and MR's, which egress through the DC's rather than their branch site) to reach the dashboard and (as I understand it) the VPN registry server (or is VPN registry only for site-to-site VPN tunneling?).
 
Should I also build an internal Mgmt connection, or is that un-needed?
 
Would the WAN ports only need to be in the VLAN that will provide the Guest clients their DHCP address? Or, should my WAN ports live in a Mgmt VLAN for internal access AND have a tagged VLAN for the Guest clients?
 
Or, should I configure LAN ports to connect to my Mgmt network and the WAN ports only for Guest tunneling? And, does it matter whether it's the LAN or WAN ports I provide NAT and a path out to the dashboard?
 
Another question regarding the VPN registry and behavior of the MX/MR. In the SSID tunneling document it describes the behavior between MX/MR from the remote-site SSID tunneling perspective, where they each traverse their own local FW's. In my case, the MX/MR will all be within the same routing domain, and there is a direct path between the two without a FW in between. I assume that the SSID tunnel and guest traffic *DOES NOT* hairpin at the edge FW, and that the tunnels between the MR Guest SSID and the MX are built across the inside network?
 
One more related question. In the branch office, do I need to carve out a local subnet for the guest clients? Or can I drop both Corp and Guest SSID's into the same VLAN, and then the Guest SSID clients would tunnel to the MX to pull their IP addresses? Would the Guest clients also have a local IP or only the IP handed out by the MX?
 
Thank-you for any assistance, Parker
 
5 Replies 5
Ryan_Miles
Meraki Employee
Meraki Employee

It would essentially be this. I have this set up in my lab.

 

I'll attempt to answer all the questions from above.

 

The VPN MX will only have one IP on the WAN 1 interface. This is the mgmt IP and how it talks to dashboard (of course via upstream NAT). A guest SSID can tunnel via L2 from the AP to the MX and egress onto a L2 VLAN present on the switchport connected to the MX. In my example, that's VLAN 600. That VLAN only exists on the link between the VPN MX and the core switch, and the core switch up to the edge firewall which has the L3 interface and DHCP scope for VLAN 600.

 

In concentrator mode you don't use the MX LAN ports at all.

 

As long as there's a route between the AP and MX the tunnel should form over the LAN path.

 

For your branch question. With a tunneled SSID the addressing works the same way it would with a WLC. The client VLAN only exists at the VPN MX and doesn't need to exist as the edge/branch.

 

In my example below I have firewall rules in two places. On the guest SSID I use L3 firewall rule deny to Local LAN. The Local LAN object means 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.

 

Also, at my edge MX I have another rule denying VLAN 600 to the RFC1918 nets. Redundant but it's a failsafe should the MR rule be changed or I want a wired guest.

 

Screen Shot 2022-06-06 at 15.52.44.png

Ryan / Meraki SE

If you found this post helpful, please give it kudos. If my answer solved your problem, click "Accept as Solution" so that others can benefit from it.

Thank-you Ryan. Some follow-up questions. As I understand it, we will connect to a LAN port at least once to perform the initial configuration for the WAN IP/mask/gateway/DNS. I believe that's a back-to-back connection between a laptop and the MX.

 

Are you saying there will never be a need again to connect directly to the MX for mgmt once initially configured? If I want, for example, to have an internal monitoring (ex. SolarWinds) detect device up/down would I want to configure the LAN ports for that purpose? 

 

At the branch, would you just bind both Corp and Guest SSID's to the same VLAN, so I wouldn't need to build a L3 subnet at the branch for Guest clients?

 

And, for VLAN 600 in your example, does that subnet need to be scoped to have enough addresses to support the projected number of clients being tunneled to that device?

 

Lastly, if we only configure WAN interfaces for an HA pair, I assume that network is where the VRRP address also sits, or is there a VRRP address for ever VLAN the MX's connect to?

 

Thank-you, Parker

As mentioned here if you need to set a static IP on a MX you can use the local status page accessible by the dedicated mgmt port (if your MX model has one) or connect a laptop to a LAN port.

 

After initial setup you no longer use any LAN port in Concentrator mode. Reference

 

Mgmt of any MX regardless of mode is via the WAN port(s) talking to dashboard.

 

At a branch a guest tunneled SSID looks like this example config. In my example VLAN 600 only exists in the DMZ and the upstream edge MX. The DMZ MX is what places the tunneled guest onto the (local to the DMZ MX) VLAN.

Screen Shot 2022-06-08 at 20.52.13.png

 

And yes your DHCP server, whatever it is, needs to be scoped to have enough IPs for all guests.

 

And yes in Concentrator mode the HA VRRPs go out on the WAN interface. Again, you don't use any LAN ports.

 

All that said, is your branch using a MX appliance and if so is it doing AutoVPN back to the same guest anchor MX? If so, this likely won't work as outlined in this doc mentioning the double tunnel problem.

 

Also, is there a specific reason to tunnel guests back to a central location? The far easier way to provide guest WLAN in Meraki is by using NAT mode. Guests are segmented from corp devices, P2P isolation is enabled, no need to manage any DHCP scopes, and no need for more MXs sitting in a DMZ.

Ryan / Meraki SE

If you found this post helpful, please give it kudos. If my answer solved your problem, click "Accept as Solution" so that others can benefit from it.

Hello Ryan,

Can you please answer a few questions?

Why do you have VLAN 85 on WAN 1 IP?
Do I Firewall NAT the MX WAN IP for VLAN 85 or 600?
Do I configure DHCP on the MX or Firewall for VLAN 600?

Brady2
Comes here often

Hi everyone.  We are in the process of rolling out Meraki AP's in all of our locations.  We have WAN connectivity between all sites on the 10.0.0.0/8 network.  We purchased a pair of MX-450's to be VPN concentrators at one of our sites.  The goal is to do SSID tunneling for our Guest wireless network.  Ideally, we want to tunnel the traffic to the firewalls, then egress directly out to the internet from the MX450's.  Initially, based on the documentation, I had thought that we had to deploy the firewalls in a One-Armed Concentrator mode.  Now I'm reading that we can do a Routed Mode Concentrator deployment, which was good news for us, as we do not want to have to add any additional infrastructure to make this work.  The question now, for us, is how the tunnels are built.  Ideally, the tunnels between the AP's and the firewalls will be established between the private 10.x.x.x ip addresses of the AP's and the Firewall's LAN interface.  But nobody from Meraki Sales or Support has been able to answer that question.

 

https://documentation.meraki.com/MX/Deployment_Guides/VPN_Concentrator_Deployment_Guide#Deploying_a_... 

 

 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels