Business Community > Switches > Should I use an unused VLAN instead of the management VLAN as the native VLAN on trunk ports?
< Switches

Should I use an unused VLAN instead of the management VLAN as the native VLAN on trunk ports?

Should I use an unused VLAN instead of the management VLAN as the native VLAN on trunk ports?

Should I use an unused VLAN instead of the management VLAN as the native VLAN on trunk ports?
Should I use an unused VLAN instead of the management VLAN as the native VLAN on trunk ports?
2 weeks ago - last edited a week ago
Tags: #VLAN & Multi-Networks
Model: TL-SG2008   ER605 (TL-R605)   EAP610  
Hardware Version:
Firmware Version:

I am a total beginner and I am creating my home network and the security and correct VLANs segmentations is important.

Chatgpt told me that the native VLAN on trunk ports should not be the management/admin VLAN for security reasons like VLAN-hopping.

I have tried to follow that suggestion and I have set vlan 99 (an intentionally unused “parking” VLAN) as the native VLAN on trunks (see image).

image 1

 

But after I did that, all the Omada devices (router, switch and EAP) get an IP address inside VLAN 99 and they disconnect from the OC200 controller (as shown in following image).

I think the Omada devices disconnect because they don't belong anymore to the same VLAN of OC200, which is VLAN 01 (my management/admin VLAN).

Because of this unsuccessful result, I think the only possible native VLAN is the management/admin VLAN if I want to use the OC200 and that Chatgpt is wrong in suggesting a different setup.

Any help is very appreciated.

  0      
 
  0      
 
#1
Options
1 Accepted Solution
Re:Should I use an unused VLAN instead of the management VLAN as the native VLAN on trunk ports?-Solution
a week ago - last edited a week ago

  @wiub, I'd recommend using something other than "1" for the management VLAN.  In addition to security concerns, I'd prefer to not depend on "default" behavior.  Also make sure the Management VLAN enabled and set on the switch and AP.  Depending on the switch it might be under Config->VLAN Interface or Config->Services. For the AP it should be under Config->Services.  Be careful when you set the Management VLAN on the switch or AP because it's possible to lock yourself out.  This FAQ appears to cover all the details if you need a step-by-step guide. 

Recommended Solution
  1  
  1  
#2
Options
5 Reply
Re:Should I use an unused VLAN instead of the management VLAN as the native VLAN on trunk ports?-Solution
a week ago - last edited a week ago

  @wiub, I'd recommend using something other than "1" for the management VLAN.  In addition to security concerns, I'd prefer to not depend on "default" behavior.  Also make sure the Management VLAN enabled and set on the switch and AP.  Depending on the switch it might be under Config->VLAN Interface or Config->Services. For the AP it should be under Config->Services.  Be careful when you set the Management VLAN on the switch or AP because it's possible to lock yourself out.  This FAQ appears to cover all the details if you need a step-by-step guide. 

Recommended Solution
  1  
  1  
#2
Options
Re:Should I use an unused VLAN instead of the management VLAN as the native VLAN on trunk ports?
a week ago

  @D-C Thank you very much for link you provided, it is amazing! Anyway I have still so many doubts regarding that setup.


Regarding the setup shown on the link provided, I do not understand the point to change the management VLAN on the switch and EAP respectively to VLAN 30 and VLAN 40. What is the point of having a management VLAN for switch and EAP, if everything is managed and set by the OC200 Controller?

 

Also, the VLAN for the gateway and controller is kept as the default one (despite it is changed from VLAN 1 to VLAN 10), which means that on the trunk ports the controlle VLAN will remain the native VLAN (since the default is used as the native in trunks). And from what I have read the management VLAN should not be the native on trunks.

 

Thank you very much for any help!

 

  0  
  0  
#3
Options
Re:Should I use an unused VLAN instead of the management VLAN as the native VLAN on trunk ports?
a week ago

@wiub, APs can get a different VLAN for better security because they are not physically secured; i.e. bad guy/gal can unplug it and plug in their own device. This keeps them directly off the core equipment's VLAN.

 

As for default, there's the factory/industry default VLAN which is 1. Then there is the Omada Default VLAN that can be changed.  You still should be able to tag VLAN 10 on trunk ports. The updates just need to be done the the right sequence to avoid losing access to a device.

 

  0  
  0  
#4
Options
Re:Should I use an unused VLAN instead of the management VLAN as the native VLAN on trunk ports?
a week ago

  @D-C I haven't understood the AP part and how a management VLAN specific for the APs would help. Anyway thank you, you have helped me a a lot!

  0  
  0  
#5
Options
Re:Should I use an unused VLAN instead of the management VLAN as the native VLAN on trunk ports?
a week ago - last edited a week ago

  @wiub 

 

If this is your home network, there isnt really any pressing need to change the default management vlan from id 1

 

you can still fully secure it from other vlans with ACLs, but its not like there will be hundreds of people in and out of your building likely to start messing with stuff.

 

I take a different approach on my business network where the management vlan is 1 and untagged on the trunks.  All random-person accessible ports are locked to the public wifi vlan, no tagging allowed, and an enforced 1mbit bandwidth on the port (the wifi does get much mroe than this) and super-strict ACLs in place.

 

If someone has the time and inclination to get a ladder out and go 40ft in the air to get to my EAPs, or break into the rack to get to the core ports i have bigger problems

 

Everything else is RADIUS port authenticated.

  0  
  0  
#6
Options

Information

Helpful: 0

Views: 142

Replies: 5

Tags

VLAN & Multi-Networks
About Us
Press
Copyright © TP-Link Systems Inc. All rights reserved.