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 2012 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.

Andy

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.