Best practices for native VLAN configuration

Solved
federicogalarza
Here to help

Best practices for native VLAN configuration

Hi there,

 

I have read the article below which shares concepts related to general Cisco best practices on VLANs. 
 
 
Please see the concepts below mentioned in the article above.
 
  • A good security practice is to separate management and user data traffic. The management VLAN, which is VLAN 1 by default, should be changed to a separate, distinct VLAN.
  • A recommended security practice is to change the native VLAN to a different VLAN than VLAN 1. The native VLAN should also be distinct from all user VLANs. 

I would like to know what are the best practices which you usually implement in the Meraki world. Could you please share some insights? I am basically planning to use a random number for the native VLAN in a new environment which is going to be deployed in some days.

 

Thanks!

 

Federico

1 Accepted Solution
Uberseehandel
Kind of a big deal


@federicogalarza wrote:

 

 

I would like to know what are the best practices which you usually implement in the Meraki world. 

 

Thanks!

 

Federico


The general rules I adhere to are:

  • Tag all VLANs
  • Set up a Management VLAN
  • Set up an Isolated Guest VLAN (and SSID)
  • Do not use the native LAN
  • Create a faux VLAN for those cases where the configuration GUI requires a VLAN ID (make sure it goes nowhere)
  • Explicitly declare the VLANs a given switch port should pass, avoid the all option on uplinks
  • Make the firewall proscriptive rather than permissive.

There are some exceptions for certain network architectures, even so, they are usually very limited in scope. For example, at the moment we have a Meraki network within a third party network. The MX running the Meraki network has its WAN port on a native LAN that is connected to the LAN port of the external facing security appliance which uses PPPoE on its WAN uplink. This enables the dynamic external IP address supplied by the ISP to be passed to the MX and even to the Z3C connected to the MX.

 

It is simpler to set up than it is to write about it.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel

View solution in original post

36 Replies 36
kYutobi
Kind of a big deal

I mean you can choose a random native VLAN# and still go about doing everything else as you see fit. All you have to remember is that your native VLAN will not be 1. 

Enthusiast
PhilipDAth
Kind of a big deal
Kind of a big deal

With Cisco Enterprise kit the management plane is used to intiate connections into the device and control it.  It can often bve unecrypted using telnet and SNMP v1 or v2c.  Also anyone having dirtect access can attempt a DOS attack and prevent you getting into your own kit.

So there is some good reason to protect this.

 

Meraki kit uses an encrypted outbound stream to the Meraki cloud.  So I don't personally bother with a seperate management network.  You can also disable the Meraki local status page to further protection.

The only special exception you could consider is when using SSIDs with WPA2-Enterprise mode.  However a feature was recently added to allow RADIUS traffic to be sent over a seperate VLAN.

Personally I tend to use the one VLAN.

 

Changing the native VLAN is mostly related to preventing VLAN hopping attacks.  If this is of a concern you should use a different native VLAN on trunk ports between switches.  For safety, this should be a VLAN not in use in the network.  You want every valid VLAN to be tagged between switches.

You don't really need to use it in other places.

Personally, I wouldn't worry about it.

 

RumorConsumer
Head in the Cloud

@PhilipDAth So if I change my default vlan to 192.168.3.0/24 which all my APs and network infrastructure lives on plus maybe an invisible SSID called admin that I can log into for access to that vlan, and then create another vlan for all my user traffic and SSID, this meets your spec for VLAN config, yes? 

 

Additionally, on the MX's physical ports, I change the Allowed VLANs tag from ALL to the specific numbers that will be active on those ports and then all is set, correct? 

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
PhilipDAth
Kind of a big deal
Kind of a big deal

Yes, that is what I would do.

RumorConsumer
Head in the Cloud

You da Kiwi. Thanks a lot!

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
RumorConsumer
Head in the Cloud

@PhilipDAth followup

 

As I am moving from the ALL VLANs allowed to specific tagging on all my switches, for the admin SSID, which I want to have access to all VLANs (I think?), if I have 4 VLANs, is this what this part of the access control panel should look like?

 

RumorConsumer_0-1595674351061.png
Followup 2 I may have answered my own question - Hmm actually all I care about on this network is it having access to the default VLAN so I can access all my wired infrastructure. So really I would only want that VLAN # under "All other APs", correct? 

 

Followup 3 - and does it matter that the default VLAN is still VLAN ID 1 even though I changed the subnet? From your comments above you seem less vigilant about that and if its fine as is Id rather not change it. 

 

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
PhilipDAth
Kind of a big deal
Kind of a big deal

Nope.  I would leave the default VLAN as 1, and then bridge the SSID(s) into their respective VLANs.

 

Having a default VLAN of 1 means you can easily do things like a factory reset a Meraki device or replace a piece of hardware and do nothing more than plugging it back in again.

Uberseehandel
Kind of a big deal

As @PhilipDAth says leave VLAN 1, but don't use it. If something "odd" is going on, the odds are the perps will use VLAN 1 as an egress. Not using VAN 1 makes it easier to monitor attempts to penetrate the network.

 

Does this happen - yes. Does it all come from China - no.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
RumorConsumer
Head in the Cloud

@Uberseehandel but ok to have the switches hanging out on vlan 1, nothing more, yes?

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
RumorConsumer
Head in the Cloud

One more question for you guys.

 

So in the world of VLANs...

 

If I have a wired device that I desire to join a certain subnet/VLAN combo when its connected to a switch, is the VLAN-based method for making sure that happens designating it a port and then assigning that port with only one VLAN's traffic? Like on an MX for example, if you allow all VLANs on all ports as is default, when you plug in an ethernet port, does it Default (maybe answers my question right there) to the default VLAN's subnet for a DHCP lease? And if I did NOT want it to join that subnet, the next thing would be to configure the port it connects to only pass one VLAN's (4 in this case) traffic to make sure it got the right subnet's lease? Could I also handle this with a MAC address based DHCP assignment? 

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
PhilipDAth
Kind of a big deal
Kind of a big deal

Only ports going to other network devices should be configured as trunk ports.

 

All other ports should be configured as an access port, and an access port can only be in a single VLAN at a time.

RumorConsumer
Head in the Cloud

I see- so the port feeding an AP with multiple SSIDs on multiple VLANs would be a trunk port, but for single devices that live on one VLAN they should be access.

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
Uberseehandel
Kind of a big deal


@RumorConsumer wrote:

@Uberseehandel but ok to have the switches hanging out on vlan 1, nothing more, yes?


It is more secure to avoid using VLAN 1 for anything. Put switches and APs on the Management VLAN, which most definitely should not be VLAN 1. 

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
RumorConsumer
Head in the Cloud

@Uberseehandel Ok. So then my question is, is it as simple as changing the VLAN ID here from 1 to some other number? And because its called Default, does that mean that all the switches recognize it as the Default VLAN? So lets say I change it to 8. I will need to add 8 to all my trunk ports on switches, but because its called Default does that mean that all my APs will automatically move to it? Thats what Im trying to figure out. VLAN 1 is just a number, but is the name Default the only thing that designated the default VLAN on a network? 

 

Put another way, is there a way to leave my Default VLAN as 1, but then tell my switches and APs to live on another VLAN? I dont think I understand the distinction between the "default VLAN" and what makes my switches and APs fetch an IP from a particular VLAN/subnet combo. 

 

RumorConsumer_0-1595929046958.png

 

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
Uberseehandel
Kind of a big deal

I must have expressed myself poorly.

 

I always ensure that the options of ALL and DEFAULT are not used.

 

It doesn't matter what the default network is, avoid using it. The entire concept of a default value is insecure, inherently.

 

As far as the example you have given is concerned, I'd observe:

 

  • Why call a VLAN Default (is it a mistake)?
  • Why give the VLAN 192.168.3.0/24 an ID of 1?

You don't need a default VLAN. If you need to enter a VLAN value, when it is not required, use 101 (think about it).

 

Always reference VLANs explicitly, not generically. Refer to them by their unique VLAN ID. Individually declare the VLANs to be passed by a trunk port. Declare the specific VLAN ID on access ports.

 

 

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
CptnCrnch
Kind of a big deal
Kind of a big deal

In case you‘re wondering why @Uberseehandel strongly advises against using Vlan1: historically, there has been something called „VLAN hopping“ that leveraged the default VLAN to „hop“ into others that should notbe accessible by the attacker.

 

Please find more information here: https://portunreachable.com/vlan-hopping-vulnerability-527ee506dae3

RumorConsumer
Head in the Cloud

Thank you both. I’m kind of getting it. The thing i still don’t understand is how will my switches and APs know where to get their IP from? What determines which VLAN leases IPs to layer 2 devices?

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
Uberseehandel
Kind of a big deal

The switches and APs are on the Management VLAN. They get their IP address from the Management VLAN DHCP server on the MX.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
RumorConsumer
Head in the Cloud

Ok - thanks for going slow with me here. How does one define the "management VLAN"? Is it the VLAN labelled default? What makes it so? Right now, the IPs my switches and APs are leasing IPs from the range current ascribed to VLAN1 aka "Default". What designates a VLAN the management VLAN?

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
RumorConsumer
Head in the Cloud

@Uberseehandel OK I think I figured it out. Tell me if I got this right. To make a management VLAN, Id create another VLAN (lets say VLAN 5), and then I would change this:

 

RumorConsumer_1-1595944654850.png

 

I would select VLAN 5 from the "native VLAN" dropdown. This would tell anything connected at Layer 2 to join that VLAN. Then I would change ALL VLANs under "allowed" to the ones needed over each trunk port. I think thats the piece I was missing - to change the native VLAN on the wired ports.

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
Uberseehandel
Kind of a big deal

have you tried it ?

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
RumorConsumer
Head in the Cloud

No I’ll need to populate my other switches with the new vlan number so it all works. Did i get the right idea though??

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
Uberseehandel
Kind of a big deal

What you are proposing looks very like what I have, so I suggest you proceed. Don't forget to explicitly declare the VLANs to be passed on the uplinks, and to pass the Management VLAN ID as well as the SSID VLAN IDs to the access points.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
RumorConsumer
Head in the Cloud

Yes I think I have figured it out. I just had literally forgotten that the actual ports on the MX determine the native vlan and that I was to configure them accordingly. Thanks for your patience. It makes sense now. The APs and the switches will all grab their IP from whatever the native VLAN is set to on the trunk originating at the port on the MX. 

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
Uberseehandel
Kind of a big deal


@federicogalarza wrote:

 

 

I would like to know what are the best practices which you usually implement in the Meraki world. 

 

Thanks!

 

Federico


The general rules I adhere to are:

  • Tag all VLANs
  • Set up a Management VLAN
  • Set up an Isolated Guest VLAN (and SSID)
  • Do not use the native LAN
  • Create a faux VLAN for those cases where the configuration GUI requires a VLAN ID (make sure it goes nowhere)
  • Explicitly declare the VLANs a given switch port should pass, avoid the all option on uplinks
  • Make the firewall proscriptive rather than permissive.

There are some exceptions for certain network architectures, even so, they are usually very limited in scope. For example, at the moment we have a Meraki network within a third party network. The MX running the Meraki network has its WAN port on a native LAN that is connected to the LAN port of the external facing security appliance which uses PPPoE on its WAN uplink. This enables the dynamic external IP address supplied by the ISP to be passed to the MX and even to the Z3C connected to the MX.

 

It is simpler to set up than it is to write about it.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
CharlesIsWorkin
Building a reputation

I appreciate reading through your responses! Sorry to necro this thread but I figured it wasn't too old?

 

I was wondering if you would use your Management VLAN (changed from VLAN 1) as the native VLAN on Trunks for between switches?

Also, would you use the trunks native vlan to be the management vlan when connecting to a server with a virtual switch in it?

 

@PhilipDAth  @Uberseehandel 

RumorConsumer
Head in the Cloud

I think my question would be how would you not use the native VLAN as the management VLAN? The native VLAN is what assigns IPs to switches and APs, no? So wouldn't you want to be on that VLAN to interface with all those pieces of hardware?

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
EQLC
Conversationalist

Hello RumorConsumer,

 

I think what you were missing was the Management VLAN setting.... Navigate to Switch -> Switch Settings, at the top you define the Management VLAN. All your APs and Switches will try to grab an address from this VLAN.

 

Screen Shot 2022-06-29 at 3.48.14 PM.png

 

Uberseehandel
Kind of a big deal


@CharlesIsWorkin wrote:

 . . .

I was wondering if you would use your Management VLAN (changed from VLAN 1) as the native VLAN on Trunks for between switches?

Also, would you use the trunks native vlan to be the management vlan when connecting to a server with a virtual switch in it?

 

@PhilipDAth  @Uberseehandel 


I believe it is more secure to avoid using a native VLAN on trunks and to explicitly list the VLAN traffic to be passed. In some instances, the software will require that a native VLAN be entered; if this occurs, then enter the VLAN ID of a non-existent VLAN. For fairly self-evident reasons I choose to use VLAN 101 (aka Room 101).

MerakiTrunkPort.png

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
RumorConsumer
Head in the Cloud

@Uberseehandel - so if i understand this correctly, the native VLAN does not have to be added to trunks and the switches and APs will still lease IPs from the native VLAN subnet? If that is the case, then how do you, yourself, from a different "management" VLAN, access the switches and APs? Btw I think sometimes you think I am asking a more complex question than I actually am. The answer to this, like the above question where I didnt realize I could change the native VLAN on my wired MX ports, may be very simple. 

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
Uberseehandel
Kind of a big deal

@RumorConsumer 

I do not add the native VLAN to anything. To do so risks giving spurious legitimacy to wild-weasel packets.

Group PolicyGroup PolicyVLAN SchemaVLAN SchemaWAP Port (Trunk)WAP Port (Trunk)

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
RumorConsumer
Head in the Cloud

Eric_Cartman.png

 

Ok, I can google it later. So if it is not the native VLAN that determines what subnet/IPs your switches and APs lease from, how do you determine what subnet they belong to?

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
Uberseehandel
Kind of a big deal

A DHCP server is configured for each VLAN. Access ports (as opposed to Trunk ports) have a VLAN, a device connected to a port or a WiFi AP will be issued with an appropriate IP.

 

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
RumorConsumer
Head in the Cloud

understood, but from what i understand you wont be using access ports to connect to switches and APs as they themselves will be carrying several VLANs. I thought they all should be trunk ports carrying all needed VLANs. Only supplying a switch with one VLAN seems antithetical to the notion.

Networking geek since high school where I got half of a CCNA. Played Marathon II and Infinity over localtalk.
Made many a network over the years, now de facto admin of a retreat center with some of this fine Meraki hardware.
Fortune 100 Tech veteran/refugee.
Uberseehandel
Kind of a big deal


@RumorConsumer wrote:

understood, but from what i understand you wont be using access ports to connect to switches and APs as they themselves will be carrying several VLANs. I thought they all should be trunk ports carrying all needed VLANs. Only supplying a switch with one VLAN seems antithetical to the notion.


Connections between

  • gateways and switches
  • switches and switches
  • switches and Wi-Fi access points

are effected by using trunk ports, with no native VLAN and the VLANs required to be passed are explicitly declared. This is illustrated in my earlier post which included a screen shot of Switch Port The Gimp / 10

There is no point in only passing a single VLAN to a switch, because that VLAN would have to be the Management VLAN and non-management traffic would not pass.

Look more closely at all the screen shots I have posted you will see how this works.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
Iridium79
Getting noticed

I don't do native vlans i leave it blank.  I have the management vlan as a tagged network.

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