Probleme mit DHCP Relay und Firewalls

Mitglied: lcer00

lcer00 (Level 2) - Jetzt verbinden

22.01.2021 um 09:32 Uhr, 1160 Aufrufe, 12 Kommentare

Hallo zusammen,

wir haben einen DHCP-Server (Windows 2012r2) zentral. Netze außerhalb des lokalen Netzes des Servers sind per DHCP-Relay angebunden. DHCP-Relay-Agents sind 2 Router (1x OPNSense 1, Bintec be.ip). beim Aufräumen (Firewallregeln entrümpeln etc.) bin ich auf ein Problem gestoßen:

Ich hatte angenommen, dass die DHCP-Clients keine Verbindung zum DHCP-Server benötigen, da das DHCP-Protokoll aus Client-Sicht am DHCP-Relay-Agent endet. Dies scheint nicht so zu sein, verschiedene Clients versuchen den DHCP_Server direkt zu kontaktieren. Z.B.

DHCPREQUEST Quelle: Client_in_anderem_subnetz Ziel: DHCP-Server

Was ich hier nicht verstehe - woher haben die die Adresse des DHCP-Servers? Müssten die nicht alle Pakete vom DHCP-Relay-Agent bekommen?

Die RFCs zu DHCP und BOOTTP drücken sich da igendwie vor einer konkreten Beschreiben des DHCP_RELAY Mechanismus (vielleicht habe ich es auch nur nicht gefunden).


Zweites Problem: Einer der DHCP_Relay_Agents (die OPNSense) sendet DHCPOFFER-Broadcasts auf ein Interface, für das DHCP-RELAY gar nicht aktiviert ist. Das ist eigentlich ein OPNSense-Problem. Hier stellt sich die Frage, wo der Fehler liegt. Werden solche Broadcasts an alle Schnittstellen gesendet (ich meine so etwas für früher mal gelesen zu haben)?

Meine eigentliche Frage: Kann mir jemand auf die Sprünge helfen, was beim DHCP_Relay denn nun Standard? Bevor ich eine fehlerhafte DHCP-Client oder DHCP-Relay-Agent Implementation unterstelle, würde ich gerne wissen, was richtig und was falsch wäre. Seltsam finde ich jedenfalls, dass Firewallregeln für DHCP oft global für IN+OUT / ANY / UDP Port67+68 (quasi eine Scheunentorregel) beschrieben werden. Ich wollte das konkreter machen, momentan klappt das aber nicht.

Grüße

lcer
Mitglied: aqui
22.01.2021, aktualisiert um 09:48 Uhr
verschiedene Clients versuchen den DHCP_Server direkt zu kontaktieren. Z.B.
Das ist unmöglich und können sie gar nicht. Bzw. dann hat der Relay Agent einen Bug oder du hast ihn falsch konfiguriert und müsste ihnen ja aktiv den Server mitteilen.
DHCP basiert ja auf einem Broadcast den der Client sendet. In einem Broadcast steht ja nix von einer DHCP Server Zieladresse.
Die kennt ja einzig nur der Relay Agent und forwardet den Broadcast dann als Unicast zum Server mit seiner Absender IP. Die ersetzt der Agent.
Wenn du dir das mit einem Wireshark am Client einmal ansiehst, dann siehst du auch genau das wenn der Relay Agent sauber arbeitet.
Deine Annahme ist also richtig das die Clients keine Verbindung zum Server brauchen, das braucht logischerweise rein nur der Relay Agent.
sendet DHCPOFFER-Broadcasts auf ein Interface, für das DHCP-RELAY gar nicht aktiviert ist.
Muss man sich bei der buggy OPNsense Firmware wohl auch nicht groß wundern. Mit pfSense passiert das wenigstens nicht.
Werden solche Broadcasts an alle Schnittstellen gesendet
Nein, nur an die wo das Relaying aktiv ist und dann im Layer 2 (der Relay cacht die Mac des Clients) nur auf dem spezifischen Client Interface.
Ich wollte das konkreter machen, momentan klappt das aber nicht.
Was willst du denn da noch konkreter machen ?? Mehr Ports kennt DHCP ja gar nicht:
https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP-R ...
Bedenken solltest du aber das die Absender IP immer 0.0.0.0 ist. Eine Regel die also auf die lokale Netzwerk Adresse filtert ist dann natürlich tödlich für DHCP. Die Port 67 und 68 Filter müssen dann jeweils ANY dort haben.
Bitte warten ..
Mitglied: lcer00
22.01.2021 um 10:26 Uhr
Hallo,
Zitat von @aqui:

verschiedene Clients versuchen den DHCP_Server direkt zu kontaktieren. Z.B.
Das ist unmöglich und können sie gar nicht. Bzw. dann hat der Relay Agent einen Bug oder du hast ihn falsch konfiguriert und müsste ihnen ja aktiv den Server mitteilen.
Das hatte ich ja auch so verstanden.
DHCP basiert ja auf einem Broadcast den der Client sendet. In einem Broadcast steht ja nix von einer DHCP Server Zieladresse.
Die kennt ja einzig nur der Relay Agent und forwardet den Broadcast dann als Unicast zum Server mit seiner Absender IP. Die ersetzt der Agent.
Wenn du dir das mit einem Wireshark am Client einmal ansiehst, dann siehst du auch genau das wenn der Relay Agent sauber arbeitet.
Deine Annahme ist also richtig das die Clients keine Verbindung zum Server brauchen, das braucht logischerweise rein nur der Relay Agent.
sendet DHCPOFFER-Broadcasts auf ein Interface, für das DHCP-RELAY gar nicht aktiviert ist.
Muss man sich bei der buggy OPNsense Firmware wohl auch nicht groß wundern. Mit pfSense passiert das wenigstens nicht.
OK.
Werden solche Broadcasts an alle Schnittstellen gesendet
Nein, nur an die wo das Relaying aktiv ist und dann im Layer 2 (der Relay cacht die Mac des Clients) nur auf dem spezifischen Client Interface.
OK.
Ich wollte das konkreter machen, momentan klappt das aber nicht.
Was willst du denn da noch konkreter machen ?? Mehr Ports kennt DHCP ja gar nicht:
https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP-R ...
Bedenken solltest du aber das die Absender IP immer 0.0.0.0 ist. Eine Regel die also auf die lokale Netzwerk Adresse filtert ist dann natürlich tödlich für DHCP. Die Port 67 und 68 Filter müssen dann jeweils ANY dort haben.

Na ja, die Adresse ist (eigentlich) 0.0.0.0/32, nicht 0.0.0.0/0, also müßte z.B. 0.0.0.0/32 + 192.168.4.0/24 ja passen.

Grüße

lcer
Bitte warten ..
Mitglied: aqui
22.01.2021, aktualisiert um 12:05 Uhr
also müßte z.B. 0.0.0.0/32 + 192.168.4.0/24 ja passen.
Nein, denn die Source IP ist 0.0.0.0/32 und Destination IP 255.255.255.255 da ja ein All Network UDP Broadcast !
Logisch, denn der DHCP Client kennt das IP Netz ja vorher gar nicht !
Nimm den Wireshark zur Hand und sieh dir das doch selber einmal an !
Request:
dhc1 - Klicke auf das Bild, um es zu vergrößern
Inhalt des Requests:
Hier im Beispiel ohne Relay IP da das Segment ohne Relay arbeitet.
dhc2 - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: lcer00
22.01.2021, aktualisiert um 13:04 Uhr
Zitat von @aqui:

also müßte z.B. 0.0.0.0/32 + 192.168.4.0/24 ja passen.
Nein, denn die Source IP ist 0.0.0.0/32 und Destination IP 255.255.255.255 da ja ein All Network UDP Broadcast !
Logisch, denn der DHCP Client kennt das IP Netz ja vorher gar nicht !
Nimm den Wireshark zur Hand und sieh dir das doch selber einmal an !
hab ich getan.

ich meinte mit
eigentlich die Filterregel für die Firewall.
0.0.0.0/32 für die broadcasts ist klar.

Es gibt wirklich keine Unicasts zwischen Client und relay bzw. Server mit etwas anderem als 0.0.0.0 als Source-IP?

Dann ist das ein unzulässiges Paket?

Grüße

lcer
Bitte warten ..
Mitglied: aqui
23.01.2021, aktualisiert um 15:30 Uhr
Es gibt wirklich keine Unicasts zwischen Client und relay bzw. Server
Ist doch auch logisch ! Denke mal nach.... Den Unicast schickt doch der Relay an den DHCP Server und NICHT der Client !
Wenn, dann müsstest du mit dem Wireshark den DHCP Server sniffern mit Filter auf die lokale IP Adresse der Firewall als Absender.
Der Relay wandelt den empfangenen Client Broadcast in einen Unicast mit der Relay eigenen IP als Absender an den DHCP Server um.

Beispiel Cisco Router:
Stinknormale Konfig:
!
interface Vlan1
ip address 172.30.1.1 255.255.255.0
!
interface Vlan10
ip address 172.30.10.1 255.255.255.0
ip helper-address 172.30.1.222
!

(.1.222 ist der DHCP Server)
DHCP Client hängt am Interface "vlan 1" und ein Wireshark an einem Switch Mirrorport der den DHCP Server Port spiegelt.
DHCP Discover vom Relay:
dhc1 - Klicke auf das Bild, um es zu vergrößern
Hier kannst du im Layer 2 sehen genau das die Absender IP die des Relays ist und die Layer 2 Mac Adresse ebenfalls die des Relays (Cisco) im vlan 1 ist.
cisco-router#sh int vlan 1
Vlan1 is up, line protocol is up
Hardware is EtherSVI, address is f0f7.5502.73b6 (bia f0f7.5502.73b6)
Internet address is 172.30.1.1/24


DHCP Offer vom DHCP Server als Antwort an den Relay:
dhc2 - Klicke auf das Bild, um es zu vergrößern

Fazit: Works as designed ! ;-) face-wink
Wenn deine Firewall da irgendwas von an unbeteiligte Interfaces flutet oder sonstwie forwardet hat die garantiert einen Bug oder ist falsch konfiguriert.
Bitte warten ..
Mitglied: lcer00
23.01.2021 um 16:42 Uhr
Hallo,

Das kann ich so alles nachvollziehen. Mein Broadcast an alle interfaces muss ich noch weiter untersuchen.

Es scheint nur so zu sein, dass beim Verlängern des Leases (und nur dann!) der DHCPREQUEST vom Client direkt an den DHCP Server geschickt wird. IP.source ist dann die IP des Clients und IP.dest die IP des Servers. Das Paket wird einfach geroutet und vom Relay nicht verändert. Der Server antwortet ebenfalls direkt. Für die Firewall bedeutet das, dass keine Regel den Verkehr zwischen Clientnetz und DHCP Server blockieren darf. Ich war davon ausgegangen, dass lediglich die IP des Relay-Agents freigegeben sein muss. Das blockiert aber alle Lease-Verlängerungen des Clientnetzes. Das von mir oben gepostete Paket ist also ein korrektes Paket, bei dem der Client um Verlängerung bittet. Hier wird zwar auch DHCPREQUEST verwendet, aber nicht als Broadcast und nicht von 0.0.0.0

Was noch relevant zu sein scheint, wenn mehrere Router zwischen Client und Server liegen, muss auf jedem ein Relay-Agent aktiviert sein. Das muss ich aber auch nochmal checken.

Grüße
Bitte warten ..
Mitglied: aqui
23.01.2021, aktualisiert um 17:06 Uhr
der DHCPREQUEST vom Client direkt an den DHCP Server geschickt
Das kann gut sein, denn im Offer steht ja die direkte DHCP Server IP drin. Folglich kann der Client ja auch den Server direkt erreichen um den Lease zu verlängern.
Für die Firewall bedeutet das, dass keine Regel den Verkehr zwischen Clientnetz und DHCP Server blockieren darf.
Das ist dann zweifelsohne richtig, jedenfalls für die DHCP Ports UDP 67 und 68.
wenn mehrere Router zwischen Client und Server liegen, muss auf jedem ein Relay-Agent aktiviert sein.
Nein, das ist (sorry) Unsinn und de facto FALSCH ! Es ist ja ein Unicast mit korrekter Absender und Empfänger IP Adresse was stinknormal geroutet wird. Router in den Hops dazwischen müssen natürlich dann niemals Relays sein. Der Relay umgeht bloss die UDP Broadcast Problematik die ja prinzipbedingt am Router endet. Niemals aber direkt routebare Unicast IP Frames. Vergiss das also... Stell dir vor ein mehrfach segmentiertes Firmennetz und da müsstest du auf allen Routehops einen Relay definieren. Das wäre unsinnig und ist auch nicht der Fall. Genau deshalb wird es ja als routebarer Unicast weitergeleitet. Weisst du als IP Profi auch selber ! ;-) face-wink
Bitte warten ..
Mitglied: lcer00
25.01.2021 um 09:42 Uhr
Hallo aqui,

die Sache ist ja richtig spannend:
Zitat von @aqui:

wenn mehrere Router zwischen Client und Server liegen, muss auf jedem ein Relay-Agent aktiviert sein.
Nein, das ist (sorry) Unsinn und de facto FALSCH ! Es ist ja ein Unicast mit korrekter Absender und Empfänger IP Adresse was stinknormal geroutet wird. Router in den Hops dazwischen müssen natürlich dann niemals Relays sein. Der Relay umgeht bloss die UDP Broadcast Problematik die ja prinzipbedingt am Router endet. Niemals aber direkt routebare Unicast IP Frames. Vergiss das also... Stell dir vor ein mehrfach segmentiertes Firmennetz und da müsstest du auf allen Routehops einen Relay definieren. Das wäre unsinnig und ist auch nicht der Fall. Genau deshalb wird es ja als routebarer Unicast weitergeleitet. Weisst du als IP Profi auch selber ! ;-) face-wink

ich habe folgendes in den Manpages von bsd gefunden: https://man.openbsd.org/dhcrelay.8
Der Relay-Server kann also im Layer-2 oder im Layer-3 Betrieb arbeiten. Das wäre zumindest ein Einstiegspunkt für die Problematik der seltsamen Broadcasts. Ob das für mein Setup eine Rolle spielt, weiß ich nicht, aber denkbar wäre es. Vermutlich ist der layer-2 Modus ein Relikt aus den frühen 90ern. Wahrscheinlich ist es tatsächlich eine Option, die DHCPREQUESTs per Broadcast-Relay-Kette bis zum Zielserver durchzureichen. Das deckt sich zumindest mit der Grafik aus Badach, Hoffmann: Technik der IP-Netze, wo eine Relay-Kette beschrieben wird. Das wird vermutlich heute nicht mehr verwendet (hast Du ja ausgeführt, und ist auch logisch so), doch ein Fehlkonfigurierter Relay-Agent hätte demzufolge die Möglichkeit, Richtung DHCP-Server per broadcast zu kommunizieren.

Ich werde da mal weiter nachgrasen.

Grüße

lcer
Bitte warten ..
Mitglied: aqui
25.01.2021, aktualisiert um 10:12 Uhr
Das wäre zumindest ein Einstiegspunkt für die Problematik der seltsamen Broadcasts.
Da hast du Recht. Bei Cisco und anderen Herstellern ist die Layer 2 Option aber per se gar nicht möglich und ausgeschlossen weil die Kommando Syntax das gar nicht hergibt:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp/command/iap-cr-b ...
Da ist es also per se immer Layer 3.
Ein kurzer Labor Test eben zeigt: Der Cisco flutet es erwartungsgemäß nicht an weitere lokale IP Ports am gleichen Gerät. Ebenso ein Ruckus ICX 7150 Switch im Layer 3 Mode macht das auch nicht. Die pfSense ebensowenig. Alle können das Relay problemlos über mehrere Routing Hops erledigen. (Router Kaskade mit OSPF dazwischen)
Mikrotik müsste ich noch testen, erwarte da aber auch das gleiche Verhalten weil es nur eine Layer 3 Option da gibt.
Wahrscheinlich ist es tatsächlich eine Option, die DHCPREQUESTs per Broadcast-Relay-Kette bis zum Zielserver durchzureichen.
Das wäre aber Protokoll technsich ziemlicher Unsinn, denn an jedem Router käme dieser Broadcast nicht weiter. Stell dir ein stark segementiertes Campus Netz eines großen Unternehmens vor mit zentraler DHCP Verwaltung. Wieviel tausend Mal willst du dann auf wieviel Interfacen immer den Relay konfigurieren...?!
Das wird vermutlich heute nicht mehr verwendet
Richtig. Das wäre ja dann nicht skalier- und managebar. In der Praxis heutiger Netze wird sowas logischerweise auch niemals gemacht aus diesen Gründen. Die fehlende L2 Option bei den Router und L3 Switchherstellern spricht da ja eine deutliche Sprache.
Möglich aber das da ein Amok laufender Prozess sowas verursacht wenn die L2 Option dort noch irgendwie im BSD Kernel aktiv ist. In der Tat spannend... ;-) face-wink
Bitte warten ..
Mitglied: aqui
18.02.2021 um 20:03 Uhr
Gibts neue Erkenntnisse ?
Bitte warten ..
Mitglied: lcer00
18.02.2021 um 20:16 Uhr
Hallo aqui,

habe das erst mal zurückgestellt. In Anbetracht dieses Threads allerdings: https://administrator.de/forum/sophos-utm-dhcp-relay-requests-ueber-tran ... sollte man aber weiter dran bleiben.

Grüße

lcer
Bitte warten ..
Mitglied: aqui
18.02.2021 um 20:30 Uhr
Deshalb die Nachfrage... 😉
Bitte warten ..
Heiß diskutierte Inhalte
LAN, WAN, Wireless
Unterschiedliche IP-Adressbereiche im Netzwerk
achkleinVor 1 TagFrageLAN, WAN, Wireless17 Kommentare

Hallo, ich stehe vor einem Problem mit der WLAN-Verbindung zum Router (Fritzbox Cable 6490). Das verbundene Notebook hat die Adresse 192.168.0.164, Gateway ist 192.168.0.149: ...

Off Topic
Microsoft und der (leidige) Datenschutz
Franz-Josef-IIVor 1 TagAllgemeinOff Topic18 Kommentare

Hello Ich möchte vorausschicken, daß ich rein prinzipiell nichts gegen Microsoft habe, eher gegen die US-amerikanische Politik 😊 Microsoft bietet die Datenverarbeitung in der ...

Off Topic
32 bit Problem
brammerVor 1 TagAllgemeinOff Topic9 Kommentare

Hallo, also das ist mal ein Problem das ich auch haben möchte eine Aktie ist mehr Wert als das die Börsensoftware darstellen kann. brammer

Hardware
Thin- oder Zero-Client für RDP und Dual-Monitor im LAN gesucht
FestplattenaufzieherVor 1 TagFrageHardware9 Kommentare

Hallo, Kurzfassung meiner Frage: Ich suche Thin/Zero-Clients (4 Stück) mit Dual-Monitor-Unterstützung für den RDP-Zugriff auf PCs in einem LAN - idealerweise lautlos und relativ ...

Windows Server
Lizenzen für Virtualisierungshost
TakworianVor 11 StundenFrageWindows Server15 Kommentare

Hallo, ich werde demnächst einen HA-Cluster aus 3 x HP DL580 in Betrieb nehmen. Der Cluster wird unter Proxmox betrieben und es sollen diverse ...

Windows 10
Windows 10 2021-04 end of life?
gelöst Paedi12Vor 1 TagFrageWindows 103 Kommentare

Hi Leute! Ich bin gerade auf der Suche, wie lange die Windows Version 2021-04 unterstützt wird. Kann aber nichts finden. Hat jemand eine Ahnung, ...

Switche und Hubs
Netgear Switch Problem bei VLAN Konfiguration
gelöst meltersVor 1 TagFrageSwitche und Hubs15 Kommentare

Hallo, ich habe einen Netgear XS716T Switch zum Testen in Betrieb genommen, komme aber mit der VLAN Konfiguration nicht so ganz klar. Bislang habe ...

Router & Routing
Suche Tipps für Selfmade-Load-Balancing-Router auf HP MicroServer Gen10+
gelöst MagicChris86Vor 1 TagFrageRouter & Routing7 Kommentare

Hi Leute, ich habe einen HP MicroServer Gen10+ Performance übrig, der bei einer Kundin rausgeflogen ist, weil sie mehr Power brauchte für Desktopvirtualisierung für ...