VLAN ID naming schemes

Introduction

Naming schemes are hard. I don’t think anyone would argue with me on that. Whether they’re for domain names, hostnames, usernames, etc, coming up with one that is informative / standalone, intuitive, flexible, consistent, and future-proof within the restrictions of a system is easy to fail at, speaking from experience.

VLAN IDs are particularly tricky because:

  1. They’re purely numeric.

  2. They’re restricted to 0 – 4095. In practice, this is actually less. For example, Ubiquiti UniFi’s restrictions are 2 – 4009.

  3. They’re frequently displayed without context of the subnet that they’re assigned to and represent.

Tip: Throughout my years in IT, one thing I’ve learned is that networks will eventually include subnets that you didn’t account for.

When I was first tasked with setting up a network to support multiple clients’ existing and future subnets after realising the above, I researched publicly-accepted VLAN ID naming schemes but each that I found quickly fell apart for our usage.

So, to demonstrate the suitability of each VLAN ID naming scheme, I will be using the following subnets as examples:

  • 10.0.250.0/24

  • 172.16.250.0/24

  • 192.168.1.0/24

Accepted naming scheme #1: Sequential or random

I don’t think I need to spend long on this one. Obviously, you’d have to use some kind of reference material like a spreadsheet to know what VLAN ID corresponds to what subnet which is far from ideal.

Accepted naming scheme #2: Third octet

The rule of this naming scheme is just to use the third octet (section) of the subnet so let’s see how that works out:

Subnet VLAN ID Result
10.0.250.0/24 250 Fail: Collision with 172.16.250.0/24.
172.16.250.0/24 250 Fail: Collision with 10.0.250.0/24.
192.168.1.0/24 1 Fail: VLAN ID 1 is reserved as the default.

Accepted naming scheme #3: First octet + third octet

So, a workaround around to #2 is to append the third octet to the first octet so let’s see how that works out:

Subnet VLAN ID Result
10.0.250.0/24 10250 Fail: Too long.
172.16.250.0/24 172250 Fail: Too long.
192.168.1.0/24 1921 Pass.

My naming scheme

So, my naming scheme is RFC 1918 “private subnet” designation (10.*.*.*/8 = 1, 172.16.*.*/12 = 2, 192.168.*.*/16 = 3) + third octet so let’s see how that works out:

Subnet VLAN ID Result
10.0.250.0/24 1250 Pass.
172.16.250.0/24 2250 Pass.
192.168.1.0/24 31 Pass.

This one is almost everything I said in my first paragraph: informative / standalone, flexible, consistent, and future-proof.

Almost everything. Like everything in life, there are tradeoffs: You have to know the rule for it to be intuitive and it probably won’t work if you need literally thousands of VLANs in one location. But hey, it’s the least worst option.

I’ve never seen anyone else suggest anything like this before, hence this post.

Update 2020/07/24: Today, I was on a Juniper JNCIA-Junos certification training webinar and I was both surprised and happy to see that they seem to agree!

View fullsize

Ben Hooper - 2020-07-24 11-51-07.png

 

My subnetting scheme

While we’re on the subject of schemes that are easy to get wrong, I thought I’d share my personal subnetting scheme. I like to use 10.<location>.<network type>.<host>/24 with the third octet starting at 0 and increasing by multiples of 8. For example:

  • 10.0.0.0/24

  • 10.0.8.0/24

  • 10.0.16.0/24

  • 10.0.232.0/24

  • 10.0.240.0/24

  • 10.0.248.0/24

The benefits of this are as follows:

  1. It’s scalable and an efficient use of IP space because the third octet being seperated by multiples of 8 means that, if needed, the existing subnets’ prefixes / masks can be expanded into the gaps or new subnets can be inserted.

  2. When combined with my preferred VLAN ID naming scheme, the VLAN IDs will be consistent across sites because VLANs are restricted to layer 2 networks. This is great for centrally-managed Wi-Fi / SSIDs, manually tagged devices, etc.

Some examples of network types that I would always try to segment are as follows:

  • Systems management such as Out-of-Band Management (OOBM) / Lights-Out Management (LOM), routers, firewalls, jumpboxes, etc.

  • Domain Controllers.

  • General servers.

  • Printers.

  • Organisation-owned End User Devices (EUDs) such as desktop PCs, laptop PCs, tablet PCs, smartphones, Remote Desktop Session Host (RDSH) servers, etc.

  • Personal-owned and guest devices.

  • Payment terminals.

    etc

Below, I have created a diagram as a visualisation of all of this:

View fullsize

Subnet diagram (2020-04-25 13-50).png

Content retrieved from: https://mythofechelon.co.uk/blog/2019/6/27/vlan-id-naming-schemes.

Aktivieren von IPv6-DHCP Server in einer Domäne

  1. netsh int ipv6 Show int
    dort die Nummer bei Idx für die Netzwerkkarte notieren
  2. netsh int ipv6 set int advertise=enabled
  3. netsh int ipv6 set route fc00:1192:1168:1178::/64 „<Name der Netzwerkkarte“ publish=yes

Nicht notwendig, wenn der Router korrekt konfiguriert ist (Schlagwort Router Advertising)

Ping in Windows erlauben:GUI, PowerShell, netsh, GPO

Ping-Request mit ping.exe

Windows blockiert Ping-Anforderungen durch eine ent­sprechende Konfigu­ration der Firewall. Diese Ein­stellung lässt sich auf mehrere Arten ändern, entweder über die grafische Konsole der Firewall, über die Kommando­zeile sowie PowerShell oder zentral über Gruppenrichtlinien.

Der Grund für das abweisende Verhalten von Windows gegenüber Ping-Requests sind Sicherheitsbedenken von Microsoft. Schließlich wird der Dienst gerne für Angriffe missbraucht, bevorzugt für Denial-of-Service-Attacken.

Änderung der Regeln nur als Administrator

Nichtsdestotrotz hat Ping nach wie vor seine Berechtigung als Diagnosewerkzeug bei Netzwerkproblemen, so dass man diese strikte Konfiguration der Firewall meistens lockern wird. In Firmennetzen kann man die damit verbundenen Risiken reduzieren, indem man die vordefinierte Firewall-Regel nur für das Profil Domäne aktiviert oder zulässige Anfragen auf bestimmte IP-Adressen beschränkt.

Für diesen Zweck stehen mehrere Werkzeuge zur Verfügung. Während Standardbenutzer die vorhandenen Einstellungen mit den Kommandozeilen-Tools ansehen können, setzt die Aktivierung von Firewall-Regeln grundsätzlich administrative Rechte voraus.

Eingehende Pings durchlassen

Das gängigste Programm zur Aktivierung der Firewall-Regeln für eingehende Pings ist die grafische Oberfläche Windows-Firewall mit erweiterter Sicherheit. Hier muss man sich als Administrator anmelden, um überhaupt die Einstellungen angezeigt zu bekommen.

Die Firewall-Regel für eingehende Ping-Anforderungen subsumiert Microsoft unter jenen für die Datei- und Druckerfreigabe.

Dort wechselt man in der linken Spalte zu Eingehende Regeln und sucht anschließend im Hauptfenster nach Datei- und Druckerfreigabe (Echo­anfor­derung – ICMPv4 eingehend). Diese Regel existiert in Ausprägungen für die Profile Domäne sowie für Öffentlich und Privat. Je nach Bedarf aktiviert man sie für ein bestimmtes oder für mehrere Profile (siehe dazu: Windows-Firewall: Regeln für Profile konfigurieren).

Zur Sicherheit lassen sich Ping-Anfragen auf bestimmte IP-Adressen und -Bereiche eingrenzen.

Öffnet man den Dialog Eigenschaften aus dem Kontextmenü dieser Regel, dann kann man dort unter Bereich => Remote-IP-Adresse die Clients, von denen Ping-Anfragen erlaubt sind, weiter einschränken. Existieren auf dem Rechner mehrere NICs, dann besteht zudem die Möglichkeit, über Lokale IP-Adressen jene festzulegen, zu denen Requests durchgelassen werden.

Ping zulassen mit PowerShell

PowerShell verfügt über eine Reihe von Cmdlets, mit denen sich die Firewall vollständig konfigurieren lässt. Für das Management der Regeln eignen sich Get-NetFirewallRule und Set-NetFirewallRule. Ersteres hilft dabei, den Status von Regeln zu ermitteln, Zweiteres kann diesen ändern.

Möchte man sich anzeigen lassen, welche Regeln für Ping zuständig sind, dann filtert man sie nach dem Begriff ICMP4:

Get-NetFirewallRule -name *ICMP4* | select name, DisplayName, Profile, Enabled | fl

Dieser Befehl gibt eine relative kurze Liste aus und zeigt unter anderem auch, für welches Firewall-Profil die Regeln gelten und ob sie aktiviert sind. Für eingehende Ping-Anforderungen in Domänen-Netzwerken ist demnach FPS-ICMP4-ERQ-In-NoScope zuständig, für die Profile Öffentlich und Privat hingegen FPS-ICMP4-ERQ-In.

Konfiguration der Firewall-Regeln für eingehende Pings mit PowerShell.

Nun kann man im nächsten Schritt die gewünschte Regel aktivieren, beispielsweise mit dem Befehl

Set-NetFirewallRule -name FPS-ICMP4-ERQ-In-NoScope -Enabled True -RemoteAddress 192.168.0.66

Er ändert nicht nur den Status der Regel FPS-ICMP4-ERQ-In-NoScope, so dass Ping-Anforderungen durchgelassen werden, sondern grenzt zusätzlich die zulässigen Hosts auf die IP-Adresse 192.168.0.66 ein. Vom Erfolg der Maßnahme kann man sich durch

Get-NetFirewallRule -name FPS-ICMP4-ERQ-In-NoScope | select name, enabled

überzeugen.

Firewall-Regel mit netsh.exe aktivieren

Wie schon in früheren Versionen von Windows steht auch weiterhin das Kommandozeilen-Tool netsh.exe für diese Aufgabe zur Verfügung. Zu seinen Nachteilen gehört nicht nur eine eigenwillige Syntax, sondern auch ein Mix aus übersetzten Namen für die Regeln und englischsprachigen Werten für die meisten Parameter.

Das netsh-Äquivalent zum obigen Aufruf von Set-NetFirewallRule würde so aussehen:

netsh advfirewall firewall set rule profile=Domain name=“Datei- und Druckerfreigabe (Echoanforderung – ICMPv4 eingehend)“ new enable=yes remoteip=192.168.0.66

Möchte man Anfragen von allen Rechnern zulassen, dann verzichtet man auf den Parameter remoteip. Will man hingegen die Regel für die Profile Öffentlich und Privat aktivieren, dann ändert man den Wert für profile auf Private,Public.

Ping erlauben über Gruppenrichtlinien

In zentral verwalteten Umgebungen wird man die Firewall-Einstellungen wahrscheinlich über GPOs konfigurieren wollen, beispielsweise für alle Rechner in einer bestimmten OU. Diese Möglichkeit bestand ebenfalls schon unter Windows 7 / 8.1, das Vorgehen ist dabei gleich geblieben. Siehe dazu meine Anleitung Ping mittels GPO erlauben in Windows 7 / 8.x und Server 2012 (R2).

Content retrieved from: https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gui-powershell-netsh-gpo.

Subnetz- und CIDR-Rechner

Eingabe
IP-Adresse
Vorbelegen:
Subnetzmaske
 
Ausgabe
Byteformat
Binärformat
IP-Adresse
 
 
Subnetzmaske
 
 
Wildcardmaske
 
 
Netzadresse
 
 
Rechneradresse
 
 
Broadcastadresse
 
 
Bitanzahl der Net-ID
 
 
Bitanzahl der Host-ID
 
Anzahl IP-Adressen
 
Max. Zahl der Knoten
 
Erste IP-Adresse
 
Letzte IP-Adresse
 
 

Download: w-hermanns.de,

Active Directory und gängige Ports

Hier eine Auflistung der gängigsten Active Directory Ports sowie gängiger Ports für Paketfilter in Firewalls.

tcp/53 DNS
tcp/88 Kerberos
tcp/135 RPC
tcp/445 sysvol share
tcp/389 LDAP
tcp/464 Kerberos password (Max/Unix clients)
tcp/636 LDAP SSL (if the domain controllers have/need/use certificates)
tcp/1688 KMS (if KMS is used. Not necessarily AD, but the SRV record is in AD and clients need to communicate with the KMS).
tcp/3268 LDAP GC
tcp/3269 LDAP GC SSL (if the domain controllers have/need/use certificates)
tcp/49152 through 65535 (Windows Vista/2008 and higher) aka “high ports”

udp/53 DNS
udp/88 Kerberos
udp/123 time
udp/135 RPC
udp/389 LDAP
udp/445 sysvol share

You can minimize the high-port range by configuring a static RPC port for Active Directory.

Restricting Active Directory RPC traffic to a specific port
https://support.microsoft.com/en-us/kb/224196

It’s usually a good idea to force Kerberos to use only tcp/ip, particularly if you have a large, complex network, or accounts are members of large number of groups/large token size.

How to force Kerberos to use TCP instead of UDP in Windows
https://support.microsoft.com/en-us/kb/244474

Active Directory Ports

DienstebeschreibungTCP/UDPPortnummern, Beschreibung
DNSTCP/UDP53
KerberosTCP/UDP88
LDAPTCP/UDP389 (LDAP, 389/TCP, LDAP Ping 389/UDP)
LDAP-SSLTCP686
Microsoft-DSTCP/UDP445
UPnPTCP/UDP1900, 2869 (UPnP Framwework für Netzwerkkommunikation unter Windows
WINSTCP/UDP1512
NetBIOSTCP/UDP137
NetBIOS DatagrammUDP138
NetBIOS Session ServiceTCP139
WINS ReplikationTCP/UDP42

Active Directory KommunikationNotwendiger Datenverkehr
Netzwerkanmeldung eines Benutzers über eine Firewall Microsoft-DS-Datenverkehr (445/TCP, 445/UDP)
Kerberos-Authentifizierungsprotokoll (88/TCP,88/UDP)
LDAP-Ping (389/UDP)
DNS (53/TCP, 53/UDP)
Computeranmeldung an einem Domänencontroller Microsoft-DS-Datenverkehr (445/TCP, 445/UDP)
Kerberos-Authentifizierungsprotokoll (88/TCP,88/UDP)
LDAP-Ping(389/UDP)
DNS (53/TCP, 53/UDP)
Herstellen einer Vertrauensstellung zwischen Domänencontrollern in verschiedenen Domänen Microsoft-DS-Datenverkehr (445/TCP, 445/UDP)
Kerberos-Authentifizierungsprotokoll (88/TCP,88/UDP)
LDAP-Ping (389/UDP)
DNS (53/TCP, 53/UDP)
LDAP (389/TCP; 686/TCP bei Verwendung von SSL)
Verifizierung einer Vertrauensstellung zwischen zwei Domänencontrollern Microsoft-DS-Datenverkehr (445/TCP, 445/UDP)
Kerberos-Authentifizierungsprotokoll (88/TCP,88/UDP)
LDAP-Ping (389/UDP)
DNS (53/TCP, 53/UDP)
LDAP (389/TCP; 686/TCP bei Verwendung von SSL)
Netlogon

Microsoft SQL Server Ports

DienstebeschreibungTCP/UDPPortnummern, Beschreibung
SQL AbfragenTCP1433
SQL MonitorTCP1434

Microsoft Exchange Server Ports

NetzwerkkommunikationNotwendiger Datenverkehr
Kommunikation mit Domänen-
controllern
LDAP-Standardprotokoll (389/TCP; 636/TCP bei Verwendung von SSL)
LDAP-Kommunikation für Standortreplikationsdienst (379/TCP)
LDAP-Kommunikation für globalen Katalog (3368/TCP; 3269/TCP bei Verwendung von SSL)
Ausgehende DNS-Anforder-ungen an einen DNS Server DNS (53/TCP und 53/UDP)
Nachrichtenaustausch zwischen Servern SMTP Datenverkehr (25/TCP; 465/TCP bei Verwendung von TLS)
SMTP Verbindungsalgorithmus (691/TCP)
Clients, die E-Mail über POP3 herunterladen POP3 (110/TCP; 995/TCP bei Verwendung von SSL)
Clients, die E-Mail über IMAP4 herunterladen IMAP4 (143/TCP; 993/TCP bei Verwendung von SSL)
Client, der Newsreader einsetzt NNTP (119/TCP; 563/TCP bei verwendung von SSL)
Webbrowser, der E-Mail von OWA herunterlädt HTTP-Protokoll (80/TCP; 443/TCP bei Verwendung von SSL)
Clients, die Sofortnachrichten verwenden RVP (80/TCP sowie Anschlüsse über 1024/TCP)
Clients, die ein Chatprotokoll verwenden IRC/IRCX (6667/TCP; 994/TCP bei Verwendung von SSL

Internetauthentifizierungsdienst (RADIUS)

DienstebeschreibungTCP/UDPPortnummern, Beschreibung
Authentifizierungsdaten-verkehrUDP1645, 1812
KontoführungsdatenverkehrUDP1813, 1646
Benachrichtigungs- und Über-wachungsdatenverkehr der QuarantänesteuerungUDP7250

Diverse gängige Netzwerkports

DienstebeschreibungTCP/UDPPortnummern, Beschreibung
PPTP VPNTCP1723 (GRE, IP/47)
L2TP VPNTCP1701, sowie IKE Port 500/UDP
SSHTCP22
HTTPTCP80
HTTPSTCP443
RDPTCP3389, Microsoft Remote Desktop Protocol
iSCSITCP3260, 860
RPC LocatorTCP/UDP135, Remote Procedure Call
Microsoft Operations ManagerTCP/UDP1270
WINSTCP/UDP1512
Microsoft Message QueueTCP/UDP1801
Microosft Desktop Air Sync ProtocollTCP/UDP2175
Microsoft Active Sync Remote APITCP/UDP2176
Microsoft OLAP3TCP/UDP2382
Microsoft OLAP4TCP/UDP2383
Microsoft .NETsterTCP/UDP3126
Microsoft Business Rule Engine Update ServiceTCP/UDP3132
Microsoft Globaler KatalogTCP/UDP3268
Microsoft Globaler Katalog mit LDAP/SSLTCP/UDP3269
Microsoft Windows File System (WINFS)TCP/UDP5009
Microsoft Small BusinessTCP/UDP5356
Microsoft DFS ReplikationTCP/UDP5722
Microsoft maxTCP/UDP6074
NTPTCP/UDP123, Network Time Protocol
NetBIOSTCP/UDP137
NetBIOS DatagrammUDP138
NetBIOS Session ServiceTCP139
RPC Dynamic AssignmentTCP1024-65535
Server Message Block, SMB over IP (Microsoft-DS)TCP/UDP445
GRE, generic routing encapsulation (if using PPTP)IP47
IPSec ESPIP50, Encapsulated Security Payload
IPSec AHIP51, Authenticated Header
EmuleTCP4661, Ausgehend
EmuleTCP4662, Eingehend
EmuleUDP4665, Ausgehend
EmuleUDP4672, Eingehend
MSN MessengerÄltere Messenger Versionen:
IN TCP 6891 – 6900
IN TCP 1863
IN UDP 1863
IN UDP 5190
IN UDP 6901
IN TCP 6901 Neue Messenger Versionen:
UDP Ports: 135, 137, 138
TCP Ports: 135, 139, 445
Ältere MSN Messenger:
(Achtung!! Alte Messenger benötigen einen großen Portbereich!!)

Ports 6891-6900 erlauben Datei Sendungen
Port 6901 ist für Audio Kommunikation
Allows Voice, PC to Phone, Messages, and Full File transfer capabilities.
Thnx to Brad King & Bill Finch Jr.
Neue MSN Messenger:
UDP Ports: 135, 137, 138,
TCP Ports: 135, 139, 445

Die gesamten Well Known Ports und Registered Ports sind auf der Homepage der IANA auf: http://www.iana.org/assignments/port-numbers zu finden.

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑