Windows: Keine IP-Adresse via DHCP. Die Daten stehen im NCB.
Nach dem Ersetzen einer pfSense durch eine Securepoint UTM erhielt ein Notebook via DHCP keine IP-Adresse mehr, natürlich (gemäß Murphys Law) das vom Chef.
Direkt grafisch hat man an dem Notebook nicht viel gesehen, es wurde zwar angezeigt, das man mit dem WLAN verbunden sei, aber kein Internet habe. In der Eingabeaufforderung mittels “ipconfig /all” sah das schon anders aus, dort fand sich eine APIPA-Adresse. Gab man die IP-Adresse mit “ipconfig /release” frei und wollte eine Neue vom DHCP-Server mittels “ipconfig /renew” erhalten bekam man folgende Fehlermeldung:
"Beim Aktualisieren der Schnittstelle "WLAN" ist folgender Fehler aufgetreten: Der im Netzwerkkontrollblock (NCB) angegebene Name ist auf einem Remoteadapter in Verwendung. Die Daten stehen im NCB."
Kurz danach recherchiert findet man z.B. diesen Beitrag:
Linuxpeter Softwareblog – Windows: Der im Netzwerkkontrollblock (NCB) angegebene Name …
Kurzum: Das Problem liegt auf der Seite des DHCP-Servers, am Client kann man nichts machen. In diesem Fall läuft der DHCP-Server auf einem Windows Server 2021 R2 Standard. Dort in die DHCP-MMC geschaut fand sich nichts verdächtiges, es gab kein Lease passend zur MAC-Adresse des betroffenen Notebooks, auch nichts mit “BAD ADDRESS” o.ä. Ein Neustart des DHCP-Server(-Dienstes) änderte an dem Problem ebenfalls nichts.
Als Workaround wurde auf dem Notebook für das WLAN-Netz die zufällige MAC-Adresse aktiviert:
Nach dem erneuten de-/aktivieren des WLANs auf dem Notebook klappte die Verbindung wieder. Vier Tage später sollte das Thema nochmal angegangen werden, also wurde die “Zufällige Hardwareadresse” wieder deaktiviert, WLAN de- und erneut aktiviert und siehe da, es läuft alles wieder wie es soll.
Es scheint als habe der DHCP-Server oder ggf. das DHCP-Relay in der pfSense oder Securepoint UTM, irgendwo etwas zwischengespeichert. Die Relays halte ich allerdings für eher unwahrscheinlich, da diese die DHCP-Anfragen lediglich an den DHCP-Server weiterreichen.
Update 18.03.2022
Das Ganze hat sich jetzt bei einer anderen Baustelle wiederholt, dort allerdings mit einem Surface-Tablet, auf dem die Option mit der zufälligen Hardwareadresse nicht verfügbar ist. Das Netz dort nutzt das DHCP-Relay einer Securepoint UTM. Das Neustarten des DHCP-Relay-Dienstes hat in diesem Fall geholfen.

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Hi,
gab es einen speziellen Grund, die pfSense zu ersetzen?
Grüße, Raimund
Einen? Mehrere.
Es handelte sich lediglich um eine Community-Edition.
Die Hardware war sind recht alt und langsam.
Die wacklige VLAN-Unterstützung (offenbar ein bekanntes Treiber-Problem mit manchen NICs) war lästig, da immer ein Neustart von Nöten war.
Das der DHCP-Daemon nicht (mehr) ohne weiteres einen DNS-Eintrag schreiben konnte, ohne das die Dienste ggf. öfters neu starteten war auch so’n Ding (keine Ahnung wie das bei der UTM ist, im Zuge des Projekts wurde da noch mehr im Netz getan). So manches was man bei der pfSense mit Plugins dazubasteln muss, was in der UTM schon drin ist, ist ebenfalls so ein Punkt. Über Support und ordentliche Hardware-Unterstützung bzw. -Integration geht es dann weiter (gibt es bei pfSense auch, aber nur bei den kommerziellen Lösungen samt Applicance).
Weiter geht es dann mit dem Punkt das es sich bei Securepoint um einen deutschen Hersteller handelt (Netgate ist amerikanisch).
Usw., usf.