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

Best practices for native VLAN configuration

SOLVED
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
3 REPLIES 3
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. 

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