Eine falsch gesetzte Subnetzmaske trennt Geräte logisch, obwohl sie im selben LAN hängen. Korrigieren Sie den Fehler, indem Sie IP-Adresse und Maske pro Host mit ipconfig oder ip addr prüfen, den DHCP-Scope am Router oder Server anpassen und statisch konfigurierte Clients auf das korrekte Präfix (z. B. /24) setzen.
Symptome
- Ping innerhalb des Subnetzes funktioniert, ins Gateway aber nicht (oder umgekehrt).
- Freigaben, Drucker oder NAS erscheinen nur sporadisch in der Netzwerkumgebung.
- DHCP vergibt Adressen, doch einzelne Clients haben keinen Internetzugang.
- Traceroute läuft sofort ins Leere oder bleibt am ersten Hop hängen.
- Meldung „Doppelte IP-Adresse erkannt
- ,obwohl der Adressraum eigentlich frei ist.
Häufige Ursachen
Statisch gesetzte, abweichende Maske
Ein Techniker hat auf einem Client oder Server eine Maske wie 255.255.0.0 gesetzt, während der Rest des Netzes mit 255.255.255.0 arbeitet. Broadcasts und ARP laufen dann in unterschiedliche Räume.
Falscher DHCP-Scope
Der DHCP-Server verteilt eine Maske, die nicht zum tatsächlichen Präfix des VLANs passt. Alle neu gebooteten Geräte übernehmen den Fehler automatisch.
VLSM-Planungsfehler
Bei Subnetting mit variabler Länge wurde ein Bereich zu klein gewählt. Hosts an der Bereichsgrenze landen rechnerisch außerhalb ihres Segments.
Kollision mit Routing-Regeln
Statische Routen oder OSPF-Areas erwarten ein anderes Präfix, als die Clients tragen. Pakete werden falsch weitergeleitet oder verworfen.
Konflikt zwischen VPN und LAN
Ein Remote-Client bekommt aus dem VPN-Pool eine Maske, die das lokale LAN überdeckt. Lokale Ressourcen sind während der VPN-Sitzung nicht erreichbar.
Schritt-für-Schritt-Lösung
- Ist-Zustand pro Host dokumentieren
Erfassen Sie auf mindestens zwei betroffenen Geräten und einem funktionierenden Referenzgerät die aktuelle IP, Maske und das Gateway. Unter Windows mit `ipconfig /all`, unter Linux mit `ip addr` und `ip route`, unter macOS mit `ifconfig` bzw. `networksetup -getinfo`. Notieren Sie auch die MAC und den DHCP-Server. - Soll-Präfix aus der Netzdokumentation ableiten
Vergleichen Sie die gefundenen Werte mit dem geplanten Adressplan. Falls keiner existiert, definieren Sie einen: pro VLAN genau ein CIDR-Präfix, ein Gateway, ein DHCP-Bereich. Rechnen Sie durch, ob alle aktuell vergebenen Hostadressen mathematisch in dieses Präfix passen. - DHCP-Server korrigieren
Öffnen Sie den zuständigen Scope auf Windows Server, im Router oder auf dem Fortigate/pfSense. Setzen Sie die Maske auf den geplanten Wert, prüfen Sie Gateway- und DNS-Optionen und speichern Sie. Anschließend an einem Testclient `ipconfig /release` und `ipconfig /renew` ausführen und die neue Konfiguration verifizieren. - Statisch konfigurierte Geräte anpassen
Server, Drucker, Kameras und Access Points hängen oft an festen IPs. Öffnen Sie deren Weboberfläche oder Netzwerkeinstellung und tragen Sie die korrekte Maske ein. Achten Sie darauf, dass die IP weiterhin innerhalb des neuen Präfixbereichs liegt, sonst verlieren Sie die Verwaltungssitzung. - Routing und ARP-Cache neu aufbauen
Auf Layer-3-Switches und Routern die Interface-Konfiguration prüfen und mit `show ip interface brief` bzw. `show ip route` gegenkontrollieren. Auf Clients den ARP-Cache mit `arp -d *` (Windows) oder `ip -s -s neigh flush all` (Linux) leeren, damit alte Zuordnungen verschwinden. - Erreichbarkeit end-to-end testen
Pingen Sie vom Client das Gateway, einen Host im gleichen Subnetz, einen Host in einem anderen Subnetz und einen externen Namen wie 1.1.1.1. Ergänzend `tracert` bzw. `traceroute`, um zu sehen, ob der erste Hop wirklich das geplante Gateway ist. - Änderung dokumentieren und Monitoring aktivieren
Tragen Sie das korrigierte Präfix, den DHCP-Scope und alle statischen Ausnahmen in die Netzdokumentation ein. Aktivieren Sie im Monitoring eine Regel, die auf abweichende Masken pro VLAN alarmiert, etwa über SNMP-Polling oder einen Nmap-Scan im Wartungsfenster.
Typische Symptome, Ursachen und schneller Fix bei Maskenfehlern
| Symptom | Wahrscheinliche Ursache | Erster Fix |
|---|---|---|
| Ping ins Gateway schlägt fehl | Maske zu eng, Gateway liegt außerhalb | Maske auf geplantes Präfix setzen |
| Nur einzelne Clients ohne Internet | Statisch gesetzte Falschmaske | Auf DHCP umstellen oder Wert korrigieren |
| Doppelte IP-Warnung | Überlappende Subnetze | Adressplan prüfen, Scope trennen |
| Drucker verschwindet aus Freigabe | Broadcast-Domain gespalten | Maske aller Geräte angleichen |
| VPN-Client sieht kein LAN | VPN-Pool überdeckt LAN-Präfix | VPN-Netz in anderen Bereich verlegen |
So beugen Sie vor
- Ein VLAN, ein Präfix, ein Gateway. Keine Mischmasken im selben Broadcast-Segment.
- DHCP-Reservierungen statt manueller IP-Vergabe, wo immer möglich.
- Adressplan versioniert ablegen und bei jeder Änderung nachziehen.
- Regelmäßiger Abgleich per Skript zwischen Soll-Präfix und tatsächlich vergebenen Masken.
Häufige Fragen
Wie erkenne ich schnell, ob die Subnetzmaske schuld ist?
Vergleichen Sie IP und Maske eines funktionierenden Geräts mit denen eines Problemgeräts. Weichen die Masken ab oder ergibt die bitweise UND-Verknüpfung von IP und Maske unterschiedliche Netzadressen, liegen die Geräte logisch in verschiedenen Netzen und können sich nicht direkt erreichen.
Muss ich alle Geräte gleichzeitig umstellen?
Idealerweise ja, weil sonst während der Umstellung zwei Subnetzdefinitionen parallel existieren. In der Praxis reicht ein Wartungsfenster: erst den DHCP-Scope anpassen, dann alle statisch konfigurierten Geräte, danach an den Clients ein Renew erzwingen. Rechnen Sie mit kurzen Verbindungsabbrüchen.
Warum funktioniert manches trotz falscher Maske?
Wenn zwei Hosts durch die falsche Maske zufällig noch in dieselbe rechnerische Netzadresse fallen, kommunizieren sie weiter direkt. Sobald ein dritter Host außerhalb dieses zufälligen Bereichs liegt oder das Gateway rausfällt, brechen Verbindungen scheinbar willkürlich ab. Genau das macht die Fehlersuche zäh.
Lassen Sie Ihre Subnetz- und IP-Struktur durch unser Netzwerkteam prüfen.