Hat man bei der Nutzung des DHCP-Relays bei einer Securepoint UTM eine ungewöhnlich hohe Last auf der UTM und wird dazu das Log (“Nur Applikations- und Kernel-Meldungen anzeigen”) mit Meldungen vom DHCP-Relay geflutet gibt es mit Sicherheit einen Fehler in der Konfiguration.
DHCP-Relays sind eine feine Sache, wenn es nur einen zentralen DHCP-Server gibt, der für mehrere Netze zuständig ist. Dabei kommuniziert das Relay über die Ports 67/udp und 68/udp, es nimmt die Broadcasts der DHCP-Clients auf und leitet Sie (in ein anderes Netz) zum angegebenen DHCP-Server weiter. In der Regel klappt dies ohne Probleme. Im Falle einer UTM von Securepoint muss man dazu dank der impliziten Regeln keine zusätzliche Portfilter-Konfiguration vornehmen. Lediglich unter
Netzwerk - Netzwerkkonfiguration - DHCP-Relay
muss für IPv4 und IPv6 die IP-Adresse des DHCP-Servers eingetragen und die genutzten Schnittstellen ausgewählt werden. Das Einzige was es zu beachten gilt ist nur die Schnittstellen respektive Netze auszuwählen, die den DHCP-Server nutzen möchten abzüglich der Schnittstelle/des Netzes in dem sich der DHCP-Server befindet!
Gibt man auch die Schnittstelle bzw. das Netz im DHCP-Relay an, in dem sich der DHCP-Server befindet führt dies zu einer Reihe von Problemen. Kurios kann dabei wirken, das manche Clients eine IP-Adresse erhalten, andere wiederum nicht. Unter Windows (in der Eingabeaufforderung) kann einem die Meldung
"Beim Aktualisieren der Schnittstelle "LAN" ist folgender Fehler aufgetreten: Der im Netzwerkkontrollblock (NCB) angegebene Name ist auf einem Remoteadapter in Verwendung. Die Daten stehen im NCB."
begegnen, andere Clients wie beispielsweise Apples iOS zeigen wiederum überhaupt keinen Fehler an, es erhält schlicht keine IP-Konfiguration und meldet keinen Internet-Zugang. Auf der UTM selbst macht sie diese fehlerhafte Konfiguration zum einen in einer höheren Last bemerkbar und das es im Log ununterbrochen Meldungen des DHCP-Relays gibt. In letzterem kann man den Ablauf beobachten:
Zunächst gibt es einen DISCOVER oder REQUEST vom DHCP-Client, darauf folgt ein OFFER vom DHCP-Server. Normalerweise würde als nächstes ein ACK folgen, aber es kommt zu einem NACK, also einer Ablehnung durch den DHCP-Server.
Schaut man sich die Meldungen genau an, erkennt man die jeweilige Schnittstelle über die die Kommunikation gerade abläuft:
REQUEST from LAN2/0.0.0.0 for 00:12:34:56:ab:cd (<hostname-des-Clients>) to 255.255.255.255 forwarded to 192.168.175.20
Wird der DHCP-Server nun beispielswiese in LAN2/A1, für gewöhnlich “internal-network”, betrieben und erscheinen Meldungen wie DISCOVER oder REQUEST auf dieser Schnittstelle, so ist diese mit Sicherheit (aus Versehen oder im Übereifer) in der Konfiguration des DHCP-Relays eingetragen worden und muss entfernt werden. Sobald man dies getan hat, geht die Last schlagartig runter und auch das Log wird wesentlich ruhiger:
Quellen
Wikipedia – Dynamic Host Configuration Protocol
Microsoft – Docs – DHCP-Subnetzauswahloptionen
ADMINISTRATOR – Probleme mit DHCP Relay und Firewalls
VirtualizationHowto – Windows Server DHCP VLAN Configuration: Detailed Guide
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.
Artikel (RSS)
XING
Schreibe einen Kommentar