We are currently using an MX60 to concentrate an SSID for remote sites using "VPN: tunnel data to a concentrator".
I'm interested in changing the subnet on which the MX60 reside, but I'm having trouble understanding exactly what will happen if I do so. The main thing which is confusing me is the original design (which I didn't do), which has the DHCP server assign the clients using the tunneled SSID an IP address on the 10.44.44.0/24 subnet. I'm suspecting that this design simply didn't consider the monitoring aspect.
For starters, I'm a bit confused about "3) Optional:", there is no list of VLANs displayed on the page where I configure the SSID to tunnel to the MX60, there is however a field where I can manually enter a VLAN ID (simply a mistake in the documentation?). I'm also however, unsure what to expect from what I think is the solution, so any help or clarification would be much appreciated.
Consider above network sketch, everything is currently set up this way with the MX60 operating in Passthrough mode. The MX100 is acting gateway for the SSID and forwards DHCP requests to the central resources etc. The only thing which is not currently active in the sketch is the "green subnet", this is what I'm trying to achieve. The reason for the change is monitoring, which we cant do for the 10.44.44.0/24 subnet.
If I tag the SSID at Remote site X with vlan 100 on the page where I configure it to tunnel to the MX60, what exactly will happen. Is the traffic tagged locally on Remote site X, or when the traffic exits the concentrator?
If it's tagged exiting the concentrator (which I'm suspecting), if I then change the switchport which connects the MX60 from access vlan 100 to a trunk and permit both vlan 10 and 100. Following I place the MX60/MX100 on the new "green subnet"/vlan 10 (with MX100 still operating as .1 in Vlan 100). Will the user traffic still continue to flow as currently?
I’ve only seen the Layer 3 Roaming with a Concentrator used once, and I’m trying to remember how it worked. From memory I believe you’re correct in what you’ve written.
When you configure the SSID you set the VLAN number, and this is the tag which is applied to the traffic as it exits the VPN concentrator MX. Between the MR and the MX it uses an IPSec tunnel between the management IP address and network of the MR and the IP address configured on the WAN1 of the VPN Concentrator MX. I think you may be right about the documentation being wrong as an MX in VPN concentrator mode has no idea what VLANs it has attached (unlike a MX in NAT/routed mode, which does).
The ‘difficult’ part is understanding the traffic flow for the SSID at the VPN Concentrator MX end when the traffic leaves the IPSec tunnel. In this regard my understanding is that the IP address on the MX is largely irrelevant - there is only one IP address on the MX, and it’s in the native VLAN, but you could have many SSIDs, with different VLANs terminating on it. Traffic receives the defined tag and is placed onto the network, essentially you create a VLAN that stretches from the MR all the way through the VPN Concentrator MX (which is effectively Layer 2 only) and out to the default gateway for the VLAN wherever that is (the MX100 in your scenario).
For traffic returning to the MR, sent from the default gateway for that VLAN (again, the MX100 in your scenario), there is no IP address on the VPN Concentrator MX for that VLAN. My understanding is that the VPN Concentrator MX will listen for, and forward all the Layer 2 frames into the IPSec tunnel for the clients in the VLAN that it has learnt about, essentially operating as a Layer 2 bridge/switch for the VLAN.
Now, if I’m understanding you correctly you’re essentially trying to separate the client traffic on the SSID, from the Meraki management traffic, IPSec tunnel traffic, and so forth that the VPN Concentrator MX is generating. In this case you’re on the right track. You’ll end up removing the .10 address on the VPN concentrator MX for VLAN100 and replace it with the IP address in VLAN10. The trunk between the MXs will need to have the native VLAN set to 10. And this isn’t going to be a seamless change or something you can do remotely, you’re changing the one IP address that the VPN Concentrator MX communicates with the rest of the world, and all the IPSec tunnels will need to re-establish. But it should be possible.
Would be nice to have some documentation or official confirmation of these things.
The native vlan for the MX60 was a good pointer, good gotcha there.
So I'll move the MX60 onto the new subnet with the MX100, then trunk the ports on the switch connected to the mx60 with allowed vlan 100 and native vlan 1, then match this on the trunk towards the mx100. Then the management and user traffic will be separated on vlan 1 (native) & 100?
I've a follow up question (maybe not befitting here, but it's relevant to the solution so I'll post it). Currently the MX100 is configured to drop untagged traffic, meaning I'll have to assign the native vlan (1) to the port of the MX100 in order for this to work. Is there anything specific which happens when you create an interface and assign it to the native vlan on an MX device, thinking of things like sourcing DHCP messages for example, or anything at all which is good to know?
Instead of changing the configuration on the MX100 (enabling the native vlan on the port towards the switch), I'll resort to setting up a new vlan (non-native) and tag that on the uplink configuration on the MX60 instead, this should also result in the end-result I'm looking for, right?
From the MX60:
This means I'll also have to permit vlan 10 to flow through over the trunks between the MX boxes ofc.
Either way should work, either with the native VLAN, or using VLAN10, so long as the MX100 is configured as a trunk port and the correct VLANs permitted. Either will separate the tunnelled traffic onto the VLAN that is configured on the MX60 WAN port, with the SSID traffic being tagged as specified in the SSID.
Personally I’d use the native VLAN, but that’s only my preference as it’s generally easier to configure the first comms to the MX if it’s on the native VLAN.