cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Best practices for native VLAN configuration

SOLVED
Highlighted
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

Accepted Solutions
Highlighted
Kind of a big deal

Re: Best practices for native VLAN configuration


@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

25 REPLIES 25
Highlighted
Kind of a big deal

Re: Best practices for native VLAN configuration

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. 

Highlighted
Kind of a big deal

Re: Best practices for native VLAN configuration

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.

 

Highlighted
Kind of a big deal

Re: Best practices for native VLAN configuration


@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

Highlighted
Head in the Cloud

Re: Best practices for native VLAN configuration

@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.
Highlighted
Kind of a big deal

Re: Best practices for native VLAN configuration

Yes, that is what I would do.

Highlighted
Head in the Cloud

Re: Best practices for native VLAN configuration

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.
Highlighted
Head in the Cloud

Re: Best practices for native VLAN configuration

@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.
Highlighted
Kind of a big deal

Re: Best practices for native VLAN configuration

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.

Highlighted
Kind of a big deal

Re: Best practices for native VLAN configuration

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
Highlighted
Head in the Cloud

Re: Best practices for native VLAN configuration

@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.
Highlighted
Head in the Cloud

Re: Best practices for native VLAN configuration

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.
Highlighted
Kind of a big deal

Re: Best practices for native VLAN configuration

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.

Highlighted
Head in the Cloud

Re: Best practices for native VLAN configuration

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.
Highlighted
Kind of a big deal

Re: Best practices for native VLAN configuration


@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
Highlighted
Head in the Cloud

Re: Best practices for native VLAN configuration

@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.
Highlighted
Kind of a big deal

Re: Best practices for native VLAN configuration

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
Highlighted
Head in the Cloud

Re: Best practices for native VLAN configuration

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

Highlighted
Head in the Cloud

Re: Best practices for native VLAN configuration

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.
Highlighted
Kind of a big deal

Re: Best practices for native VLAN configuration

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
Highlighted
Head in the Cloud

Re: Best practices for native VLAN configuration

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.
Highlighted
Head in the Cloud

Re: Best practices for native VLAN configuration

@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.
Highlighted
Kind of a big deal

Re: Best practices for native VLAN configuration

have you tried it ?

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

Re: Best practices for native VLAN configuration

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.
Highlighted
Kind of a big deal

Re: Best practices for native VLAN configuration

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
Highlighted
Head in the Cloud

Re: Best practices for native VLAN configuration

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.
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.