How to Set Up VLAN Support on Windows Server 2025
VLANs (Virtual Local Area Networks) are one of the foundational tools of network segmentation. By tagging network traffic with an 802.1Q VLAN ID, you can logically separate distinct types of traffic — management, production, storage, DMZ — across shared physical infrastructure without running separate cables or purchasing additional switches. Windows Server 2025 supports 802.1Q VLAN tagging natively on physical adapters, on LBFO team interfaces, and inside Hyper-V virtual switches. This tutorial covers all three approaches: tagging physical NICs, creating VLAN team interfaces on LBFO teams, and configuring Hyper-V VM network adapter VLANs for both access ports and trunk ports. It also addresses VLAN security considerations, inter-VLAN routing verification, and the most common configuration mistakes that lead to VLAN hopping vulnerabilities.
Prerequisites
- Windows Server 2025 (physical or virtual machine host)
- A managed switch with 802.1Q VLAN support configured on the ports connected to this server
- Understanding of your switch VLAN design: which VLAN IDs exist, their subnets, and which switch ports carry trunk or access frames
- PowerShell running as Administrator
- For Hyper-V VLAN configuration: the Hyper-V role installed
Step 1: Understand 802.1Q VLAN Tagging on Windows Server
When you assign a VLAN ID to a Windows network adapter, the adapter driver inserts an 802.1Q tag (a 4-byte field containing the 12-bit VLAN ID) into each outbound Ethernet frame. The switch reads this tag and forwards the frame only to other ports that are members of that VLAN. Inbound frames arriving with a matching tag are accepted and the tag stripped before being passed to the operating system. Frames without a tag are assigned to the switch port’s native (PVID) VLAN. This means the switch port connecting to your server must be configured as a trunk port (also called a tagged port) for VLAN tagging to work — an access port strips all tags and the VLAN assignment has no effect.
Step 2: Configure a VLAN on a Physical Network Adapter
Windows Server 2025 allows VLAN IDs to be assigned to physical adapters via the Set-NetAdapterAdvancedProperty cmdlet, which writes a registry value that the driver reads. The exact property name varies by driver — most Intel and Broadcom drivers expose it as VLAN ID or VlanID.
# Check which advanced properties the adapter exposes
Get-NetAdapterAdvancedProperty -Name "Ethernet 1" |
Select-Object DisplayName, RegistryKeyword, DisplayValue |
Sort-Object DisplayName
# Find the VLAN-related property name specifically
Get-NetAdapterAdvancedProperty -Name "Ethernet 1" -DisplayName "*VLAN*"
# Set VLAN ID 10 on the adapter (property name may differ — check output above)
Set-NetAdapterAdvancedProperty `
-Name "Ethernet 1" `
-RegistryKeyword "VlanID" `
-RegistryValue 10
# The adapter will briefly disconnect while the driver reinitialises
# Verify the VLAN ID is now set
Get-NetAdapterAdvancedProperty -Name "Ethernet 1" -DisplayName "*VLAN*" |
Select-Object Name, DisplayName, DisplayValue, RegistryValue
After setting the VLAN ID, this adapter will only communicate on VLAN 10. If your switch port carries multiple VLANs, use an LBFO team with per-VLAN team NIC interfaces (covered in Step 3) instead of assigning a single VLAN to the physical adapter directly.
Step 3: Create VLAN-Tagged Interfaces on an LBFO Team
When a server needs connectivity to multiple VLANs simultaneously, the cleanest approach is to create an LBFO team from the physical adapters (which provides redundancy) and then create one team NIC interface per VLAN. Each team NIC interface carries only one VLAN’s tagged traffic, and you assign a separate IP address to each.
# Create the LBFO team first (if not already done)
New-NetLbfoTeam `
-Name "Trunk-Team" `
-TeamMembers "Ethernet 1","Ethernet 2" `
-TeamingMode SwitchIndependent `
-LoadBalancingAlgorithm Dynamic
# Wait for the team to come online
Start-Sleep -Seconds 10
Get-NetLbfoTeam -Name "Trunk-Team" | Select-Object Name, Status
# Create a tagged interface for VLAN 10 (Production)
New-NetLbfoTeamNIC -Name "Trunk-Team-VLAN10" -Team "Trunk-Team" -VlanID 10
# Create a tagged interface for VLAN 20 (Management)
New-NetLbfoTeamNIC -Name "Trunk-Team-VLAN20" -Team "Trunk-Team" -VlanID 20
# Create a tagged interface for VLAN 30 (Storage / iSCSI)
New-NetLbfoTeamNIC -Name "Trunk-Team-VLAN30" -Team "Trunk-Team" -VlanID 30
# Assign static IP addresses to each VLAN interface
New-NetIPAddress -InterfaceAlias "Trunk-Team-VLAN10" -IPAddress "10.10.10.50" `
-PrefixLength 24 -DefaultGateway "10.10.10.1"
New-NetIPAddress -InterfaceAlias "Trunk-Team-VLAN20" -IPAddress "10.20.20.50" `
-PrefixLength 24
New-NetIPAddress -InterfaceAlias "Trunk-Team-VLAN30" -IPAddress "10.30.30.50" `
-PrefixLength 24
# Verify all team NIC interfaces
Get-NetLbfoTeamNIC -Team "Trunk-Team" | Format-Table Name, VlanID, Primary
# Verify IP assignments
Get-NetIPAddress -InterfaceAlias "Trunk-Team-VLAN*" | Format-Table InterfaceAlias, IPAddress, PrefixLength
Step 4: Verify VLAN Configuration
After configuration, verify that each VLAN interface is up, has the correct IP, and can reach its gateway. Pay attention to the native VLAN — the base team interface with no VLAN ID carries untagged frames and should be on your native/management VLAN.
# Check all VLAN-related advanced properties on all adapters
Get-NetAdapter | ForEach-Object {
$vlan = Get-NetAdapterAdvancedProperty -Name $_.Name -DisplayName "*VLAN*" -ErrorAction SilentlyContinue
if ($vlan) {
[PSCustomObject]@{
Adapter = $_.Name
VLANProp = $vlan.DisplayName
VLANValue = $vlan.DisplayValue
}
}
}
# Verify connectivity from VLAN 10 to its gateway
Test-NetConnection -ComputerName "10.10.10.1" -InformationLevel Detailed
# Verify connectivity from VLAN 20 to its gateway
Test-NetConnection -ComputerName "10.20.20.1" -InformationLevel Detailed
# Check interface statistics to confirm traffic is flowing on each VLAN interface
Get-NetAdapterStatistics -Name "Trunk-Team-VLAN10" |
Select-Object Name, ReceivedBytes, SentBytes
Step 5: Configure Hyper-V VM VLANs — Access Port Mode
In a Hyper-V environment, VMs connect to virtual switches that in turn connect to physical adapters. You can assign a VLAN ID to each VM’s virtual network adapter so that all traffic from that VM is tagged with a specific VLAN ID before leaving the host. This is the equivalent of an access port — the VM itself has no knowledge of VLANs.
# Create a Hyper-V external switch connected to a trunk-capable physical adapter
# Use SET (Switch Embedded Teaming) for Hyper-V hosts
New-VMSwitch `
-Name "ExternalSwitch" `
-NetAdapterName "Ethernet 1","Ethernet 2" `
-EnableEmbeddedTeaming $true `
-AllowManagementOS $true
# Assign VM1 to VLAN 10 (access port — VM gets untagged, switch sees VLAN 10)
Set-VMNetworkAdapterVlan `
-VMName "VM1" `
-Access `
-VlanId 10
# Assign VM2 to VLAN 20
Set-VMNetworkAdapterVlan `
-VMName "VM2" `
-Access `
-VlanId 20
# Verify VLAN assignment for each VM
Get-VMNetworkAdapterVlan -VMName "VM1" | Format-Table VMName, OperationMode, AccessVlanId
Get-VMNetworkAdapterVlan -VMName "VM2" | Format-Table VMName, OperationMode, AccessVlanId
Step 6: Configure Hyper-V VM VLANs — Trunk Mode
Some VMs need to handle multiple VLANs internally — for example, a virtual firewall, router, or network monitoring appliance. Configure those VM network adapters in trunk mode, which passes tagged frames directly into the VM, allowing the guest OS to process them.
# Configure a VM network adapter in trunk mode
# AllowedVlanIdList specifies which VLAN tags the Hyper-V switch will pass to the VM
# NativeVlanId is the VLAN for untagged frames the VM sends
Set-VMNetworkAdapterVlan `
-VMName "VirtualFirewall" `
-Trunk `
-AllowedVlanIdList "10,20,30,40" `
-NativeVlanId 1
# Verify trunk configuration
Get-VMNetworkAdapterVlan -VMName "VirtualFirewall" |
Format-Table VMName, OperationMode, NativeVlanId, AllowedVlanIdListString
# Also set VLAN on the management OS vNIC if needed
Set-VMNetworkAdapterVlan `
-ManagementOS `
-VMNetworkAdapterName "Management" `
-Access `
-VlanId 20
Step 7: Test Inter-VLAN Routing
VLANs are isolated at layer 2. For traffic to flow between VLANs, a layer-3 device must route it — typically a router, layer-3 switch, or firewall. Verify your routing configuration after setting up VLANs:
# On the Windows Server, check the routing table for VLAN subnets
Get-NetRoute -AddressFamily IPv4 | Where-Object { $_.DestinationPrefix -notmatch "^(127|169|0.0)" } |
Sort-Object RouteMetric |
Format-Table DestinationPrefix, NextHop, InterfaceAlias, RouteMetric
# Test connectivity from the server (VLAN 10) to a host on VLAN 20
# This will fail if inter-VLAN routing is not configured on the switch/router
Test-NetConnection -ComputerName "10.20.20.10" -TraceRoute
# Test with explicit source interface (useful when multiple VLANs are present)
# Use ping with -S for source IP (via cmd, since Test-NetConnection doesn't expose source IP)
ping 10.20.20.10 -S 10.10.10.50 -n 4
Step 8: VLAN Security Considerations and VLAN Hopping Prevention
VLANs provide segmentation but they are not a security boundary by themselves — misconfigured switches can allow VLAN hopping attacks. Follow these practices to close common vulnerabilities:
- Never use the native VLAN for user traffic. Set the native VLAN to an unused VLAN ID (e.g., VLAN 999) on all trunk ports. On Windows Server, ensure no team NIC interface is untagged (no VlanID set) when the switch’s native VLAN is not your intended traffic VLAN.
- Disable unused switch ports and assign them to a dedicated unused VLAN so that a device plugged into an unused port cannot access any production VLAN.
- Do not allow all VLANs on all trunks. Use explicit allowed VLAN lists on your switch trunk ports: only permit the VLANs that are actually needed on each trunk link. The Windows Server
AllowedVlanIdListparameter in Hyper-V trunk mode enforces this from the server side. - Avoid DTP (Dynamic Trunking Protocol) on Cisco switches — statically configure ports as either access or trunk to prevent rogue devices from negotiating a trunk connection.
- Use Private VLANs (PVLANs) on your switch for high-security segments such as PCI-DSS or HIPAA data — these prevent lateral movement even within the same VLAN.
# Verify no Windows adapter is unexpectedly on the native VLAN when it should be tagged
# List all adapters with no VLAN ID set (these send untagged frames)
Get-NetAdapter -Physical | ForEach-Object {
$vlanProp = Get-NetAdapterAdvancedProperty -Name $_.Name `
-RegistryKeyword "VlanID" -ErrorAction SilentlyContinue
$vlanValue = if ($vlanProp) { $vlanProp.RegistryValue } else { "Not set / 0 (untagged)" }
[PSCustomObject]@{
Adapter = $_.Name
VlanID = $vlanValue
LinkSpeed = $_.LinkSpeed
Status = $_.Status
}
}
Step 9: Audit and Ongoing Monitoring
# Generate a complete VLAN configuration report for documentation
$report = @()
# Physical adapter VLANs
Get-NetAdapter -Physical | ForEach-Object {
$prop = Get-NetAdapterAdvancedProperty -Name $_.Name -RegistryKeyword "VlanID" -ErrorAction SilentlyContinue
$report += [PSCustomObject]@{
Type = "Physical NIC"
Name = $_.Name
VlanID = if ($prop) { $prop.RegistryValue } else { 0 }
}
}
# LBFO team NIC VLANs
Get-NetLbfoTeam | ForEach-Object {
Get-NetLbfoTeamNIC -Team $_.Name | ForEach-Object {
$report += [PSCustomObject]@{
Type = "Team NIC"
Name = $_.Name
VlanID = $_.VlanID
}
}
}
# Hyper-V VM VLAN assignments
if (Get-Command Get-VM -ErrorAction SilentlyContinue) {
Get-VM | ForEach-Object {
$vmName = $_.Name
Get-VMNetworkAdapterVlan -VMName $vmName | ForEach-Object {
$report += [PSCustomObject]@{
Type = "Hyper-V VM"
Name = "$vmName / $($_.AdapterName)"
VlanID = if ($_.OperationMode -eq "Access") { $_.AccessVlanId } else { "Trunk: $($_.AllowedVlanIdListString)" }
}
}
}
}
$report | Format-Table Type, Name, VlanID -AutoSize
Conclusion
VLAN support in Windows Server 2025 is comprehensive and consistent across physical adapters, LBFO teams, and Hyper-V virtual switches. Whether you are segmenting a multi-tenant hosted environment, isolating storage traffic to a dedicated VLAN for predictable performance, or enforcing network policy boundaries between departments, the tooling is mature and entirely manageable from PowerShell. The key discipline is maintaining a clear, documented mapping of VLAN IDs to subnets and roles — both on the Windows Server side and on your physical switch — so that VLAN mismatches and security gaps can be spotted quickly. Combine VLAN segmentation with firewall rules at the inter-VLAN routing layer to ensure that segmentation provides genuine security isolation rather than simply a logical grouping that traffic can traverse freely. Revisit your VLAN design whenever network infrastructure changes — adding a new server, switch, or application tier is the most common time that native VLAN misconfigurations and overly permissive trunk policies are inadvertently introduced.