MR74 Native VLAN & Per SSID VLAN tagging - VLAN hopping attack

[Rudi]

Hi All, 

Just hoping to get some feedback about the potential security risk involved with per-SSID VLAN tagging and Meraki APs. From what I've read here: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/VLAN_Tagging_on_MR_Access_Points the MR74 sends management traffic untagged (and thus on the native VLAN on a trunk port, which is required for per-SSID VLAN tagging). However, this leaves our network open to a VLAN hopping attack. Is there anyway to change the management traffic on the MR74 to be tagged?

Thanks!

[WadeAlsup · Accepted solution]

Hi @Rudi, 

See https://documentation.meraki.com/MR/Monitoring_and_Reporting/Understanding_and_Configuring_Managemen...

I think by default, yes, the management traffic is untagged. You specify the vlan on the MR itself and allow it through your trunk port. 

Does this help your scenario? 

[Rudi]

Re-trying this now, had initially tried this but it didn't work. Though it's possible something else was causing the issue.

Will update in a few minutes. Thanks 🙂

[WadeAlsup]

@Rudi, be sure your management vLan still has a route to the internet to reach your cloud dashboard. I use reservations for all management addresses as well. 

[Rudi]

Seems to be what I want. When I tried last time my AP stopped being available on the cloud. Must have been something else getting in the way!
Thanks for the quick reply!

[PhilipDAth]

Personally, I think you are overly concerned about this attack.  To be able to do a vlan hopping attack the attacker would have to unplug the access point and then plug their machine into that same port.  They would then need to craft a double tagged packet.

If the attacker has physical access to be able to plug something in then they have a wide scope of potential attacks.

Personally, I would stick with the untagged management VLAN, and then just restrict the VLANs that are allowed on the switch port to only those required.  Then even if someone did this, they could not get to any other VLANs than the ones you have specified.

[Uberseehandel]

I found this from a Cisco person - 

• Avoid using VLAN1 and whatever native VLAN you have on your trunks to carry user traffic
• Change the native VLAN on trunks from 1 to a different unused VLAN
• Have the management VLAN to be again standalone and separate from both VLAN1 and any native VLAN you're using (this is really just a direct consequence of the previous two points)

the full post is at - https://supportforums.cisco.com/t5/lan-switching-and-routing/management-and-native-vlan-best-practic... and made by Peter Paluch

[PhilipDAth]

@Uberseehandel sure you can apply Cisco "Enterprise" mentality to Cisco Meraki.  You will loose a lot of the core Cisco Meraki philosophy if you do this - "Keeping it simple",  I'm explain the nature of the potential attack and that this represents a very low risk in this environment.  So I guess it is a matter if choosing the Meraki way and something that is very low risk versus the Enterprise approach and something that requires a lot more effort for very little gain.

[Uberseehandel]

---

@PhilipDAth wrote:

. . . something that requires a lot more effort for very little gain.

---

I guess our definitions of very little effort are quite different.