Setting up virtual local area networks or VLANs in your home network or home lab makes management of your network easier. You can use one as a guest network to share your internet connection with friends, separate off noisy devices like smart TVs, and keep IoT devices on their network so they don’t interfere with the devices that need low-latency connections. VLANs aren’t challenging to set up or use, but I’ve made several missteps along the way and seen plenty more on other people’s networks. The most common tend to be the easiest to fix, so let’s run through what those are.
Using the native VLAN for traffic
Table of Contents
Set a non-used VLAN as native and don’t define it
Managed network switches will designate a default VLAN to which all untagged traffic will go by default. Most manufacturers use VLAN 1, but it could be VLAN 0 or any other number, so it’s worth checking the manual for that particular device. Now you might be thinking that having a fallback VLAN is a good thing if traffic doesn’t get tagged at the access ports, but it’s not best practice because of security issues.
Being intentional with Layer-2 configuration is always best practice, so change the default (or native) VLAN to a number that won’t be used anywhere else. That way, if non-tagged traffic gets onto the network, it can’t go anywhere. It also helps you find any misconfigured switches or other hardware, as those devices won’t pass traffic across the network until they get ports tagged with the VLANs they should be able to use. It also prevents mismatched trunk ports if you have hardware from different manufacturers that use a differing native VLAN.
For example, on Cisco hardware:
!
interface GigabitEthernet1/1/1
switchport mode trunk
switchport trunk allow vlan 10,20,30
switchport native vlan 888
!
The second part of this security fix is to set all unused ports to access ports and give them this VLAN tag, so that any device that gets physically plugged in gets blackholed, and can’t access network appliances or resources.
Native VLAN mismatch between trunk ports
It’s all too easy to get misconfigured
It’s all too easy to misconfigure ports with either incorrect or missing tags for the VLAN(s) that are supposed to be carried along them. It’s even easier to accidentally set one VLAN tag on one side of a trunk link, and a second VLAN tag on the other, causing a mismatch. This could cause many issues, including misdirected traffic when packets hit the other side of the trunk link, VLAN hopping of malicious actors, or problems with network plane messages not passing correctly.
It’s worth remembering that when you set up VLAN trunk numbers, the setting is locally significant, and you’ll need to set the corresponding VLAN trunking numbers on every other managed switch in the network segment that you want traffic to pass through. That will stop any mismatches and allow traffic to flow as designed. If you’ve got spanning tree running on your managed switches it’s less of a practical issue as the switches will detect the issue and notify you, but it’s an important thing to set up correctly.
Not setting up a management VLAN
It’s always easier to have a dedicated VLAN for accessing your network hardware
There are many reasons why your carefully created VLANs might stop contacting a specific managed switch, firewall, or router on your network, and most of them require physical access to the hardware to resolve. That will be even more likely if your VLANs are in your home lab, because of the frequency of changing hardware and configurations, but there’s a simple solution.
Setting up a management VLAN and ensuring that all trunk ports between your network appliances will pass this VLAN tag will go a long way toward being able to recover from a disaster. And because you’ve enabled it across the network, if you can’t reach a particular network device, you can move to whichever other appliance on the edge of your network you can access easily and try again. It’s less likely that multiple VLAN connections have gone down for whatever reason, and you should be able to connect and see what was causing the issue.
Plus, if you add some anti-lockout rules to that VLAN, you can get in even if firewall configurations block all other VLANs or LANs from access. Enabling SSH to port 22, traffic to port 443, and ICMP ping on the management VLAN should do the job, so you can always get back into your firewall or switches.
Incorrect VLAN port assignments
The difference between access and trunk ports is essential
Every managed switch on your network will allow its ports to be set up as access or trunk when you’re setting up your VLANs. Both of these are essential to configure correctly for the VLAN to work, and can both contribute to issues. Access port configuration should be double-checked against the design of the network to ensure all client devices or wireless access points are placed on the correct VLAN, and are connected physically to the correct port. Access points generally only support one VLAN, except for when VoIP is involved, in which case each access point will support two VLANs, the local network and the VoIP VLAN.
Trunk ports are set up to allow communication between all the VLANs in the network by default. That makes setup easier, but it’s a nightmare for troubleshooting and security, and I’ve seen enough switches left on the defaults to know this is a widespread issue. Use VLAN pruning to only allow traffic from the specifically tagged VLANs to go along the trunk ports to their destinations, reducing broadcast traffic overhead.
Breaking VLANs by adding unmanaged switches
You might think that unmanaged switches would just pass any datagrams they’re sent to the next destinations, but in reality, that has wildly different outcomes when using VLAN-tagged traffic. The behavior of unmanaged switches is unpredictable, changes between manufacturers or even with product ranges, and is best avoided when using managed switches to set up VLANs. You’ve spent all that time setting up VLANs. Don’t ruin it by adding cheap, unmanaged switches to any point in the network.
Typical issues with unmanaged switches when VLAN tagged traffic hits them include:
- Dropping all traffic with VLAN tags
- Dropping all traffic
- Passing everything
- Passing everything but changing the tag to VLAN 1
- Only passing packets with no tag
None of these outcomes are acceptable and will break your carefully created VLANs and any firewall rules that you set up between them. It’s not worth the cost of mental anguish to save a few dollars by not getting managed switches for every segment of your planned network, and will undoubtedly cause headaches in the long run.
VLANs aren’t difficult when sticking to best practices
Setting up VLANs on your network is good practice, whether it’s to segment away noisy IoT devices or to learn new things in your home lab without affecting the other internet users in your home. Many of the common mistakes I’ve seen while researching and learning about my own network can be solved fairly easily, and only require a methodical approach to troubleshooting.
