Jan 22, 2021

9429

Probleme mit DHCP Relay und Firewalls

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

Please also mark the comments that contributed to the solution of the article

Content-Key: 643448

Url: https://administrator.de/contentid/643448

Printed on: April 19, 2024 at 16:04 o'clock

14 Comments

Latest comment

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.

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.

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

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:

Inhalt des Requests:
Hier im Beispiel ohne Relay IP da das Segment ohne Relay arbeitet.

Zitat von @aqui:

also müßte z.B. 0.0.0.0/32 + 192.168.4.0/24 ja passen.

hab ich getan.

ich meinte mit

0.0.0.0/32 + 192.168.4.0/24

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?

Ethernet II, Src: Deciso_00:2b:16 (f4:90:ea:....), Dst: Microsof_c8:78:00 (00:15:...)
Internet Protocol Version 4, Src: 192.168.200.100, Dst: 192.168.0.10
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 336
    Identification: 0xf9b9 (63929)
    Flags: 0x00
    Fragment Offset: 0
    Time to Live: 254
    Protocol: UDP (17)
    Header Checksum: 0x7823 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.200.100
    Destination Address: 192.168.0.10
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Request)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x0d68010f
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 192.168.200.100
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: APCbySch_15...
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Request)
    Option: (57) Maximum DHCP Message Size
    Option: (255) End
    Padding: 000000000000000000000000000000000000000000000000000000000000000000000000…

Dann ist das ein unzulässiges Paket?

Grüße

lcer

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:

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:

Fazit: Works as designed !

Wenn deine Firewall da irgendwas von an unbeteiligte Interfaces flutet oder sonstwie forwardet hat die garantiert einen Bug oder ist falsch konfiguriert.

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

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 !

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.

ich habe folgendes in den Manpages von bsd gefunden: https://man.openbsd.org/dhcrelay.8

The server might be a name, address or interface. dhcrelay will operate in layer 2 mode when the specified servers are interfaces, otherwise it will operate in layer 3 mode.
...
-i interface The name of the network interface that dhcrelay should attempt to configure. For layer 3 mode at least one IPv4 address has to be configured on this interface.

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

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

Gibts neue Erkenntnisse ?

Hallo aqui,

habe das erst mal zurückgestellt. In Anbetracht dieses Threads allerdings: Sophos UTM DHCP-Relay - Requests über Transfernetz sollte man aber weiter dran bleiben.

Grüße

lcer

Deshalb die Nachfrage... 😉

Ich denke ich hab die Lösung, hatte das gleiche Phänomen bei einem Kunden.
Es lag am Parallelbetrieb.

Alte Firewall: 10.10.10.1
DHCP: 10.10.10.10
Neue Firewall 10.10.10.254

Neues Netz 10.12.12.0

Ich hab auf dem DHCP einen Packet Capture gemacht, sehe als Client die 10.10.10.254 und im Relay Agent die 10.12.12.1, es kommt aber kein Reply raus. Der DHCP hat als Standardgateway noch die alte 10.10.10.1.
Testweise hab ich dann für 10.12.12.0 eine Netzroute auf 10.10.10.254 gelegt und schon gings. Einen Sinn konnte ich nicht wirklich erkennen, aber ich arbeite auch recht selten mit DHCP relay. Ich hab dann 3 mal (in Worten: drei) die Route gelöscht, DHCP neu gestartet am Client ipconfig /release .. wieder keine IP bekommen, dann route wieder rein, neustart, release .. IP bekommen. Ich denke es ist/war reproduzierbar und man findet diesbezüglich auch wenig weil es wohl nur im Parallelbetrieb Probleme macht.

Normalerweise schreibe ich nicht in so alte Threads aber es war der 2te Hit in Google wenn man nach dem Problem sucht.

BTW. so buggy ist OPNsense jetzt auch wieder nicht ;)

Einen Sinn konnte ich nicht wirklich erkennen

Nachdenken.... Wenn der DHCP Reply über einen anderen Pfad kommt als der Sender wird das Paket verworfen. Wäre dem nicht so könnte man den Relay nach Belieben sabotieren.
Es ist also logisch das man bei einem Parallelbetrieb von Router oder Firewall zwingend einen Relay deaktiviert !
Ausnahmen gibt es nur wenn die parallelen Maschinen in einem Cluster arbeiten mit VRRP, CARP usw.
Solche Binsenweisheiten sollte man als Netzwerk Admin aber auch kennen.

Kann Kollege @lcer00 seinen Thread auch nun endlich mal als erledigt schliessen !
How can I mark a post as solved?

German Question Protocols Networks

Hotly discussed

Check of ZFW Firewallgleixnerd - 3 Comments

How to set up and configure a Linux GRE tunnelAlexWisha - 3 Comments

WIREGUARD VPN ON UDM PRO BEHIND FRITZBOX - HANDSHAKE DID NOT COMPLETEjstricker - 3 Comments

End of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment