Skip to main content

Server Networking Standards

DTC standards for server network configuration across all managed client environments. These apply to physical Hyper-V hosts, virtual machines, and standalone servers.

Hyper-V Host Networking

VLAN Placement

Hyper-V hosts are always placed on the INFRA VLAN. This separates host management traffic from production client traffic and provides an additional layer of network segmentation.

NIC Teaming (SET — Switch Embedded Teaming)

All Hyper-V hosts use SET (Switch Embedded Teaming) for NIC redundancy and bandwidth aggregation.

Configuration standards:

  • Team up to 4 NICs into a single SET team
  • Load balancing mode: Dynamic only (Hyper-V Port is also acceptable but Dynamic is preferred)
  • Team usage: VM traffic and Management traffic only
  • Storage traffic interfaces are NOT teamed — storage NICs use iSCSI Multipathing (MPIO) instead of NIC teaming. Teaming storage traffic introduces unpredictable latency and is not compatible with iSCSI best practices.

SET team configuration example (PowerShell):

# Create a SET team with dynamic load balancing
New-VMSwitch -Name "VMS" -NetAdapterName "NIC1","NIC2","NIC3","NIC4" -EnableEmbeddedTeaming $true -AllowManagementOS $true

# Verify the team
Get-VMSwitch | Select-Object Name, EmbeddedTeamingEnabled, NetAdapterInterfaceDescription
Get-VMSwitchTeam -Name "VMS"

Why SET over traditional NIC teaming:

  • SET is the only supported teaming method for Hyper-V virtual switch traffic
  • Traditional LBFO teaming is deprecated in Server 2025
  • SET integrates directly with the Hyper-V virtual switch

Storage Networking

  • iSCSI interfaces: Dedicated NICs, not part of the SET team
  • MPIO (Multipath I/O): Use for iSCSI redundancy and load balancing across multiple storage NICs
  • Storage VLAN: If a dedicated storage VLAN exists, iSCSI NICs should be on that VLAN

Server IP Assignment — DHCP Reservations Over Static

All servers should be on DHCP with a reservation on the firewall. This is a change from traditional practice where servers always got static IPs.

Why DHCP reservations for servers:

  • Centralized IP management on the firewall
  • DHCP reservations auto-register hostnames with DNSMASQ on the firewall (workgroup environments)
  • Eliminates the need to manually manage static DNS entries for reserved devices
  • Reduces configuration drift when IPs need to change

Exceptions — devices that MUST have static IPs:

  • DNS servers (Domain Controllers running Windows DNS) — must be reachable before DHCP is available
  • DHCP servers (the firewall itself) — can't get an address from itself
  • Gateways (firewall, secondary routers) — same reason

Static DNS entry requirements for statically assigned servers:

EnvironmentWhere to create static DNS entries
Active DirectoryWindows DNS Server on the DC only. The firewall's Forward Domain rule forwards AD queries to the DC, which resolves them. No static DNS entries on the firewall needed.
Workgroup / Cloud-onlyStatic A records on the firewall only

In AD environments, static DNS entries go in Windows DNS Server on the DC only. The firewall's Forward Domain rule forwards AD domain queries to the DC, which resolves them from its own zone. The firewall does not need static entries for AD environments... it just forwards the query and the DC answers. In workgroup/cloud-only environments, static entries go on the firewall since there is no Windows DNS Server.

VM VLAN Placement

Domain Controllers and Windows DNS Servers

Windows Active Directory Domain Controllers (and VMs running Windows DNS Server) should be on the CORP VLAN, not the INFRA VLAN.

Why CORP VLAN, not INFRA:

AD Domain Controllers use a wide range of dynamic ports that make firewall pinholing impractical:

  • RPC dynamic port range: 49152-65535
  • LDAP: 389/TCP, 636/TCP (LDAPS)
  • Kerberos: 88/TCP/UDP
  • DNS: 53/TCP/UDP
  • SMB: 445/TCP (SYSVOL, NETLOGON)
  • Global Catalog: 3268/TCP, 3269/TCP
  • WINS/NetBIOS: 137-139
  • AD Web Services: 9389/TCP
  • Plus DFSR replication, certificate services, and more

Placing DCs on the INFRA VLAN would require opening so many firewall ports between INFRA and CORP that you'd effectively negate the segmentation benefit. Every domain-joined workstation needs to reach the DC for authentication, GPO processing, DNS queries (forwarded from the firewall), and Kerberos ticket operations. Keeping DCs on the CORP VLAN alongside the endpoints they serve is simpler, more reliable, and doesn't meaningfully reduce security posture.

Exception: A dedicated DNS-only server (not a DC, just running DNS forwarding) could theoretically live on the INFRA VLAN. But DTC doesn't use this pattern — our DCs serve the DNS role.

Other Server VMs

VM RoleRecommended VLANNotes
Domain Controller / DNS ServerCORPSee above — too many dynamic ports for INFRA isolation
File Server / Print ServerCORPNeeds to be accessible to all production endpoints
SQL Server (dental PMS database)CORPDental software on workstations connects directly
BDR / Backup applianceINFRA or dedicated Backup VLANOnly needs to reach servers, not endpoints
NAS / SANINFRA or dedicated Storage VLANAccessed by servers, not directly by workstations
Management VMs (monitoring, RMM relay)INFRAManagement traffic belongs on INFRA
Back to top