39
OPNSense, DHCP mit Relay, immer 2x Request, 2 ACK und 2 Leases
Hallo,
ich wechsle von einer Zyxel Firewall zu OPNsense und habe bei DHCP eine seltsame Änderung festgestellt.
Das Setting:
- Kea DHCP Server auf VM, VLAN 50, 192.168.50.56
- Debian Client , VLAN 10, 192.168.10.110, Gateway zur OPNSense 192.168.10.1
- OPNSense mit Relay für VLAN10 zu Server 192.168.50.56
Im Normalfall läuft das so ab: Beim Booten macht der Client einen DHCP-Request per Broadcast, der Request wird vom Relay aufgenommen und an den DHCP-Server weitergeleitet, dann folgt das übliche Handshake.
Danach hat der Client seine IP-Adresse (192.168.10.110) und die Adresse vom DHCP-Server (192.168.50.56).
Später folgt nur noch eine regelmässige Erneuerung der Adresse mit einem REQUEST und einem ACK.
Und hier bei diesem Erneuerungvorgang macht die OPNSense etwas seltsames.
So sieht ein Trafficmitschnitt auf dem Client aus:
Client 192.168.10.110 REQUEST -> Server 192.168.50.56
Server 192.168.50.56 ACK -> Client 192.168.10.110
Relay via Gateway 192.168.10.1 ACK -> Client 192.168.10.110
Grundsätzlich erwarte ich hier keine Antwort vom Relay mehr. Ich weiss auch nicht, warum das Relay hier dazwischenfunkt. Der Client hat die Anfrage direkt an den DHCP-Server gesandt und kein Broadcast gemacht.
Auf dem DHCP-Server sieht es dann so aus:
Client 192.168.10.110 REQUEST -> Server 192.168.50.56
Relay via Gateway 192.168.10.1 REQUEST -> Server 192.168.50.56
Server 192.168.50.56 ACK -> Client 192.168.10.110
Server 192.168.50.56 ACK -> Relay via Gateway 192.168.10.1
Dementsprechend hab ich im Log von Kea DHCP auch immer 2 Leaseeinträge (mit der gleichen IP).
Grundsätzlich funktioniert das, ich halte es aber für falsch und bei Zyxel war das auch nicht so.
Ist das ok? Und woher weiss das Relay, bei einem direkten Request von Client zu Server, dass da überhaupt was läuft? Der Verkehr läuft natürlich über die Firewall, da es 2 verschiedene VLANs sind. Trotzdem merkwürdig.
ich wechsle von einer Zyxel Firewall zu OPNsense und habe bei DHCP eine seltsame Änderung festgestellt.
Das Setting:
- Kea DHCP Server auf VM, VLAN 50, 192.168.50.56
- Debian Client , VLAN 10, 192.168.10.110, Gateway zur OPNSense 192.168.10.1
- OPNSense mit Relay für VLAN10 zu Server 192.168.50.56
Im Normalfall läuft das so ab: Beim Booten macht der Client einen DHCP-Request per Broadcast, der Request wird vom Relay aufgenommen und an den DHCP-Server weitergeleitet, dann folgt das übliche Handshake.
Danach hat der Client seine IP-Adresse (192.168.10.110) und die Adresse vom DHCP-Server (192.168.50.56).
Später folgt nur noch eine regelmässige Erneuerung der Adresse mit einem REQUEST und einem ACK.
Und hier bei diesem Erneuerungvorgang macht die OPNSense etwas seltsames.
So sieht ein Trafficmitschnitt auf dem Client aus:
Client 192.168.10.110 REQUEST -> Server 192.168.50.56
Server 192.168.50.56 ACK -> Client 192.168.10.110
Relay via Gateway 192.168.10.1 ACK -> Client 192.168.10.110
Grundsätzlich erwarte ich hier keine Antwort vom Relay mehr. Ich weiss auch nicht, warum das Relay hier dazwischenfunkt. Der Client hat die Anfrage direkt an den DHCP-Server gesandt und kein Broadcast gemacht.
Auf dem DHCP-Server sieht es dann so aus:
Client 192.168.10.110 REQUEST -> Server 192.168.50.56
Relay via Gateway 192.168.10.1 REQUEST -> Server 192.168.50.56
Server 192.168.50.56 ACK -> Client 192.168.10.110
Server 192.168.50.56 ACK -> Relay via Gateway 192.168.10.1
Dementsprechend hab ich im Log von Kea DHCP auch immer 2 Leaseeinträge (mit der gleichen IP).
Grundsätzlich funktioniert das, ich halte es aber für falsch und bei Zyxel war das auch nicht so.
Ist das ok? Und woher weiss das Relay, bei einem direkten Request von Client zu Server, dass da überhaupt was läuft? Der Verkehr läuft natürlich über die Firewall, da es 2 verschiedene VLANs sind. Trotzdem merkwürdig.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1589798666
Url: https://administrator.de/contentid/1589798666
Ausgedruckt am: 22.11.2024 um 17:11 Uhr
39 Kommentare
Neuester Kommentar
Ich habe kein Relay im Einsatz, aber für mich sieht das nicht ok aus. Vielleicht kann unser lieber Kollege @aqui das aufdröseln. Bis dahin:
Nach RFC2131 4.3.2 muss der Renew-Request unicast zum Server sein, mithin darf das Relay von diesem gar nichts mitbekommen.
Entsprechendes gilt für die Antwort des Servers. Die geht nicht ans Relay sondern an den Client direkt.
Vielleicht kannst Du die Mitschnitte dann auch noch im Bild einstellen?
Viele Grüße, commodity
Nach RFC2131 4.3.2 muss der Renew-Request unicast zum Server sein, mithin darf das Relay von diesem gar nichts mitbekommen.
so no relay agents will be involved in its transmission
Das entspricht Deiner Sicht der Dinge.Entsprechendes gilt für die Antwort des Servers. Die geht nicht ans Relay sondern an den Client direkt.
DHCP server will trust the value in 'ciaddr', and use it when replying to the client.
Dein beschriebener Mitschnitt am Client kann insofern IMO nicht vollständig sein. Der Request vom Relay aus in Richtung Server kann ja nur durch den Client angestoßen worden sein:- Würde der Client hier broadcasten, würde das Relay reagieren und an den Server weiterleiten. Der Server bekäme aber nichts direkt.
- Würde der Client (korrekt) unicasten, würde der Server direkt antworten, das Relay wäre aus dem Spiel.
Vielleicht kannst Du die Mitschnitte dann auch noch im Bild einstellen?
Viele Grüße, commodity
Läst sich auch in einem kurzen Test auch nicht nachvollziehen oder reproduzieren mit einem akltuellen OPNsense Release. In Ermangelung eines Kea DHCP musste der gute alte ISC DHCP Server auf einem Debian Bookworm herhalten.
Wireshark Trace am Client:
Wireshark Trace des Client Traffics am Server:
Works as designed! 👍 (Nur beim ersten Client Request nach dem Booten!)
Klassisches DHCP Standard Verhalten mit nur einem einzigen Lease, nämlich dem des Clients, was der Output dhcp-lease-list dann auch erwartungsgemäß bestätigt. Wo sollte denn auch ein weiterer Lease herkommen wenn die Firewall eine übliche statische Adressierung hat?!
Fazit: Zu 98% ein Konfig Fehler im OPNsense Setup oder des DHCP Servers.
- LAN2 = 172.30.20.0/24 = Client Segment mit aktivem Relay, OPNsense IP: .20.1
- LAN3 = 172.30.10.0/24 = DHCP Server Segment (ISC-DHCP mit 2 Subnet Scopes, IP: .10.1), OPNsense IP: .10.254
Wireshark Trace am Client:
Wireshark Trace des Client Traffics am Server:
Works as designed! 👍 (Nur beim ersten Client Request nach dem Booten!)
Klassisches DHCP Standard Verhalten mit nur einem einzigen Lease, nämlich dem des Clients, was der Output dhcp-lease-list dann auch erwartungsgemäß bestätigt. Wo sollte denn auch ein weiterer Lease herkommen wenn die Firewall eine übliche statische Adressierung hat?!
Fazit: Zu 98% ein Konfig Fehler im OPNsense Setup oder des DHCP Servers.
99,9 
Viele Grüße, commodity
Viele Grüße, commodity
1
Sie sieht es bei mir aus:
Das DHCP Log ist jetzt von anderen Geräten, aber man sieht, wie sich immer alles 2x registriert.
Ich hab hier ein Setting rein zum Testen, mit eigenem Internetanschluss, neuer OPNsense auf einem MiniPC und Proxmox auf einen anderen MiniPC. Dort läuft in einer VM Kea-DHCP und in der anderen VM der Testclient.
Dieser doppelte DHCP Verkehr ist mir seit Anfang aufgefallen. Seit dem letzten Update von OPNSense kann man neu ein DHCP-Relay für jedes VLAN einzeln erstellen, vorher ging nur entweder Relay oder eingebauter DHCP-Server. Das seltsame Verhalten war aber auch vorher so. Und das auch bei IPv6.
Mit OPNSense kenn ich mich noch nicht gut aus. Ich weiss noch nicht mal, wo dort die Konfigurationsdateien und Logs der einzelnen Dienste versteckt sind. Die GUI ist nicht grad auskunftsfreudig.
Ich versuch mal den Traffic auf der OPNSense zu analysieren. Trotzdem natürlich für weitere Tipps dankbar.
PS: Konfigurationsfehler des Kea-DHCP Server halt ich für unwahrscheinlich, den kenn ich recht gut. Ausserdem macht er ja genau das, was man von ihm verlangt hat: 2 Anfragen -> 2 Antworten.
Der Client
7 2024-05-23 14:49:11.045413 192.168.10.110 192.168.50.56 DHCP 342 DHCP Request - Transaction ID 0x396f6d54
8 2024-05-23 14:49:11.047144 192.168.50.56 192.168.10.110 DHCP 374 DHCP ACK - Transaction ID 0x396f6d54
9 2024-05-23 14:49:11.047156 192.168.10.1 192.168.10.110 DHCP 374 DHCP ACK - Transaction ID 0x396f6d54
DHCP Server
979 2024-05-23 19:00:02.451455 192.168.10.110 192.168.50.56 DHCP 342 DHCP Request - Transaction ID 0x396f6d54
980 2024-05-23 19:00:02.451474 192.168.10.1 192.168.50.56 DHCP 342 DHCP Request - Transaction ID 0x396f6d54
981 2024-05-23 19:00:02.452240 192.168.50.56 192.168.10.110 DHCP 374 DHCP ACK - Transaction ID 0x396f6d54
982 2024-05-23 19:00:02.452703 192.168.50.56 192.168.10.1 DHCP 374 DHCP ACK - Transaction ID 0x396f6d54
DHCP Log
192.168.5.40,90:ef:68:cc:e5:64,01:90:ef:68:cc:e5:64,3600,1716544500,5,0,0,nxc,0,
192.168.5.40,90:ef:68:cc:e5:64,01:90:ef:68:cc:e5:64,3600,1716544500,5,0,0,nxc,0,
192.168.5.47,b8:ec:a3:ac:61:35,01:b8:ec:a3:ac:61:35,3600,1716544501,5,0,0,ap47,0,
192.168.5.47,b8:ec:a3:ac:61:35,01:b8:ec:a3:ac:61:35,3600,1716544501,5,0,0,ap47,0,
192.168.22.110,7e:76:7b:7c:ba:e1,01:7e:76:7b:7c:ba:e1,3600,1716544519,22,0,0,,0,
192.168.22.110,7e:76:7b:7c:ba:e1,01:7e:76:7b:7c:ba:e1,3600,1716544519,22,0,0,,0,Das DHCP Log ist jetzt von anderen Geräten, aber man sieht, wie sich immer alles 2x registriert.
Ich hab hier ein Setting rein zum Testen, mit eigenem Internetanschluss, neuer OPNsense auf einem MiniPC und Proxmox auf einen anderen MiniPC. Dort läuft in einer VM Kea-DHCP und in der anderen VM der Testclient.
Dieser doppelte DHCP Verkehr ist mir seit Anfang aufgefallen. Seit dem letzten Update von OPNSense kann man neu ein DHCP-Relay für jedes VLAN einzeln erstellen, vorher ging nur entweder Relay oder eingebauter DHCP-Server. Das seltsame Verhalten war aber auch vorher so. Und das auch bei IPv6.
Mit OPNSense kenn ich mich noch nicht gut aus. Ich weiss noch nicht mal, wo dort die Konfigurationsdateien und Logs der einzelnen Dienste versteckt sind. Die GUI ist nicht grad auskunftsfreudig.
Ich versuch mal den Traffic auf der OPNSense zu analysieren. Trotzdem natürlich für weitere Tipps dankbar.
PS: Konfigurationsfehler des Kea-DHCP Server halt ich für unwahrscheinlich, den kenn ich recht gut. Ausserdem macht er ja genau das, was man von ihm verlangt hat: 2 Anfragen -> 2 Antworten.
Hallo Hans,
kannst Du vielleicht Paketmitschnitte (zunächst auf dem Client) machen? Wenn der Client nur einen einzelnen Request schickt, is t ja die Frage, wieso das Relay ebenfalls anfragt. Am Paket kann man sehen, ob es ein Unicast oder ein Brodcast und welchen Inhalt es hat.
Hast Du die Frage schon im OPNsense-Forum gestellt? Vielleicht hat jemand das dort schon erlebt.
Viele Grüße, commodity
kannst Du vielleicht Paketmitschnitte (zunächst auf dem Client) machen? Wenn der Client nur einen einzelnen Request schickt, is t ja die Frage, wieso das Relay ebenfalls anfragt. Am Paket kann man sehen, ob es ein Unicast oder ein Brodcast und welchen Inhalt es hat.
Hast Du die Frage schon im OPNsense-Forum gestellt? Vielleicht hat jemand das dort schon erlebt.
Viele Grüße, commodity
Dein Beispiel zeigt ein DHCP Handshake beim Booten, wenn der Client noch keine IP hat. Das funktioniert bei mir auch.
Netzwerk Neustart beim Client und das ist das Ergebnis auf dem DHCP-Server:
87 2024-05-24 13:48:32.942675 192.168.10.110 192.168.50.56 DHCP 342 DHCP Release - Transaction ID 0x462bcb18
88 2024-05-24 13:48:32.942693 192.168.10.1 192.168.50.56 DHCP 342 DHCP Release - Transaction ID 0x462bcb18
89 2024-05-24 13:48:33.060243 192.168.10.1 192.168.50.56 DHCP 342 DHCP Discover - Transaction ID 0xbc7ad66d
90 2024-05-24 13:48:33.061003 192.168.50.56 192.168.10.1 DHCP 374 DHCP Offer - Transaction ID 0xbc7ad66d
91 2024-05-24 13:48:33.061465 192.168.10.1 192.168.50.56 DHCP 347 DHCP Request - Transaction ID 0xbc7ad66d
92 2024-05-24 13:48:33.061907 192.168.50.56 192.168.10.1 DHCP 374 DHCP ACK - Transaction ID 0xbc7ad66dMan beachte aber noch die beiden vorgängigen RELEASES. Das ist falsch. Der Release dürfe auch nur 1x von 192.168.10.110 kommen.
Netzwerk Neustart beim Client und das ist das Ergebnis auf dem DHCP-Server:
Was meinst du mit Neustart?? Z.B. WLAN Interface mal aus- und wieder einschalten usw.?!Kann ich gerne auch nochmal testen...
DHCP auf der OPNsense selber im Relay Segment und Segment des Servers hast du hoffentlich deaktiviert bzw. inaktiv. Richtig?!
DHCP auf der OPNsense selber
hatte ich auch schon überlegt, aber er sagt ja oben (Hervorhebung von mir)Auf dem DHCP-Server sieht es dann so aus:
...
Server 192.168.50.56 ACK -> Client 192.168.10.110
Server 192.168.50.56 ACK -> Relay via Gateway 192.168.10.1
...
Server 192.168.50.56 ACK -> Client 192.168.10.110
Server 192.168.50.56 ACK -> Relay via Gateway 192.168.10.1
Viele Grüße, commodity
Zitat von @aqui:
Kann ich gerne auch nochmal testen...
DHCP auf der OPNsense selber im Relay Segment und Segment des Servers hast du hoffentlich deaktiviert bzw. inaktiv. Richtig?!
Netzwerk Neustart beim Client und das ist das Ergebnis auf dem DHCP-Server:
Was meinst du mit Neustart?? Z.B. WLAN Interface mal aus- und wieder einschalten usw.?!Kann ich gerne auch nochmal testen...
DHCP auf der OPNsense selber im Relay Segment und Segment des Servers hast du hoffentlich deaktiviert bzw. inaktiv. Richtig?!
Mit Neustart meine ich das Booten des Clients oder auf der Debian-Konsole sudo /etc/init.d/networking restart eingeben etc. Der Zustand also, wenn der Client seine eigene IP noch nicht kennt. Dann muss er ein Discovery von 0.0.0.0 auf 255.255.255.255 machen und diesen Request kann nur das Relay beantworten bzw. weiterleiten. Dieses Handshake funktioniert von mir aus gesehen vollständig.
Danach kennt der Client seine IP und auch die IP des DHCP-Servers. So ca. alle 15-30 Minuten fragt der Client eine Bestätigung dieser IP ab und dies sollte eben ohne Relay und Unicast direkt zum DHCP-Server sein. Dann dürfe es nur noch 1x ein REQUEST und ein ACK geben. Bei DHCP-Server kommen aber 2 REQUESTS an, eine davon von der OPNsense. Das ist falsch, finde ich.
Auf der OPNsense sind beim alten ISC-DHCPv4-Dienst alle Schnittstellen deaktiviert. Und der neue Kea-DHCP-Dienst ist gesamthaft deaktiviert.
Beim DHCRelay kann man nicht grad viele Optionen einstellen, sollte also passen. Sonst wüsste ich nichts mehr.
Also der Übeltäter ist wirklich DHCRelay.
Ich hab den Dienst einfach auf VLAN10 deaktiviert und siehe da, alles funktioniert so wie gedacht. D.h. es gibt keine anderen Störenfriede im Netz.
Aber natürlich kann so kein Client mehr booten, weil das Relay jetzt komplett fehlt.
Also für mich sieht das nach einem Bug aus, ich wüsste nicht, wo oder was ich da anders konfigurieren könnte.
Ich hab den Dienst einfach auf VLAN10 deaktiviert und siehe da, alles funktioniert so wie gedacht. D.h. es gibt keine anderen Störenfriede im Netz.
Aber natürlich kann so kein Client mehr booten, weil das Relay jetzt komplett fehlt.
Also für mich sieht das nach einem Bug aus, ich wüsste nicht, wo oder was ich da anders konfigurieren könnte.
Ich hatte das auf dedizierten Interfaces ausprobiert und nicht auf VLAN Interfaces. Wäre ggf. auch nochmal einen Test wert ob es sich dort anders verhält.
Ich wiederhole den Test nochmal mit der "Bestätigung" ober der Wireshark da was anderes zeigt.
Eine Setup Frage noch: Hast du beim Relay unten die Agent Info aktiviert oder nicht?
Ich wiederhole den Test nochmal mit der "Bestätigung" ober der Wireshark da was anderes zeigt.
Eine Setup Frage noch: Hast du beim Relay unten die Agent Info aktiviert oder nicht?
Du hast Recht! Es sieht so aus als ob das FW Interface selber fälschlicherweise im DHCP partizipiert was nicht sein darf.
Ein Vergleich des Relays auf einem Cisco Catalyst L3 Switch, 1100er Router und einem Ruckus ICX L3 Switch im Vergleich zeigt dieses Verhalten erwartungsgemäß nicht!
Sieht in der Tat nach einem DHCP Relay Bug im aktuellen Release beim Keepalive aus.
Trace der gesendeten Pakete am Client:
172.30.20.102 = Client IP im Relay Segment
172.30.20.1 = OPNsense IP
172.30.10.1 = DHCP Server IP
172.30.10.254 = OPNsense IP
Trace wurde ohne Haken in der "Agent Information" beim Relay Setup gemacht. Ob der Haken dort einen Unterschied im Verhalten ausmacht müsste man nochmal checken.
https://docs.opnsense.org/manual/dhcp.html#dhcrelay
Trace der korrespondierenden Pakete am Server:
Ein Vergleich des Relays auf einem Cisco Catalyst L3 Switch, 1100er Router und einem Ruckus ICX L3 Switch im Vergleich zeigt dieses Verhalten erwartungsgemäß nicht!
Sieht in der Tat nach einem DHCP Relay Bug im aktuellen Release beim Keepalive aus.
Trace der gesendeten Pakete am Client:
172.30.20.102 = Client IP im Relay Segment
172.30.20.1 = OPNsense IP
172.30.10.1 = DHCP Server IP
172.30.10.254 = OPNsense IP
Trace wurde ohne Haken in der "Agent Information" beim Relay Setup gemacht. Ob der Haken dort einen Unterschied im Verhalten ausmacht müsste man nochmal checken.
https://docs.opnsense.org/manual/dhcp.html#dhcrelay
Trace der korrespondierenden Pakete am Server:
Sieht in der Tat nach einem Bug im aktuellen Release aus.
0,1 % - ist ja wie im Lotto hier 
@aqui, die IP-Adresse des Servers ist 172.30.10.1 oder? Oben steht ".30.1 = DHCP Server IP"
Kannst Du mal bitte schauen, ob der Request, den der Client schickt, denn ein (wie der Standard erwartet: ) Unicast ist?
Wenn ja, heißt das dann für die OPNsense, dass sie den Unicast-Traffic auf DHCP filtert und dann mit den Daten des Paketes selbst beim Server anfragt? Das klänge für mich nach mehr als einem kleinen Bug. Wieso schaut die OPNsense (erlaubten) Inhalt überhaupt an? Der Paketfilter hat doch bloß zu schauen, ob die Adressierung nach dem Regelwerk erlaubt ist und dann zu forwarden bzw. zu routen.
Wenn nein, was verwendet Ihr für Clients? Dem Apple-Gedöns traue ich ja nie so recht
Viele Grüße, commodity
die IP-Adresse des Servers ist 172.30.10.1 oder?
Danke für den Hinweis. 👍 Ist korrigiert!!ob der Request, den der Client schickt, denn ein Unicast ist?
Das ist er.
was verwendet Ihr für Clients?
Winblows 10 (22H2)Dem Apple-Gedöns traue ich ja nie so recht
Na na na...🧐 Da Unix Unterbau verhält der sich in der Regel standardkonformer als Winblows.
Danke, dass du das getestet hast, ich weiss, wieviel Zeit man damit vertun kann
Agent Information hab ich nicht angehackt, weil ich diese Option nicht brauche. Aber jetzt nochmal testweise versucht und es hat keine Änderung gebracht. Damit wird die DHCP Option 82 mitgesandt, was wohl nur in komplexeren Settings von Interesse ist und auch auf dem Server unterstützt werden muss. Für meine Zwecke unnötig.
Ich glaube nicht, dass dieser Bug aus den neueren Updates kommt. Meiner Meinung nach war der schon letztes Jahr da, nur hatte ich nicht die Musse das weiter zu verfolgen.
Was ich nicht verstehe, wie der DHCRelay Dienst überhaupt dazu kommt zu reagieren. Wenn der Client ein Paket direkt an den Server sendet, sollte das Relay eigentlich netzwerktechnisch nichts davon mitbekommen.
Nachtrag Edit: Ich merk grad ich hab hier ein paar neuere Beiträge verpasst Ich arbeite mit Debian und ja der Debian-Client sendet nur noch eine Unicast Anfrage direkt an den Server. Kein Broadcast mehr. Macht ja auch Sinn
Agent Information hab ich nicht angehackt, weil ich diese Option nicht brauche. Aber jetzt nochmal testweise versucht und es hat keine Änderung gebracht. Damit wird die DHCP Option 82 mitgesandt, was wohl nur in komplexeren Settings von Interesse ist und auch auf dem Server unterstützt werden muss. Für meine Zwecke unnötig.
Ich glaube nicht, dass dieser Bug aus den neueren Updates kommt. Meiner Meinung nach war der schon letztes Jahr da, nur hatte ich nicht die Musse das weiter zu verfolgen.
Was ich nicht verstehe, wie der DHCRelay Dienst überhaupt dazu kommt zu reagieren. Wenn der Client ein Paket direkt an den Server sendet, sollte das Relay eigentlich netzwerktechnisch nichts davon mitbekommen.
Nachtrag Edit: Ich merk grad ich hab hier ein paar neuere Beiträge verpasst
Ich arbeite mit Debian und ja der Debian-Client sendet nur noch eine Unicast Anfrage direkt an den Server. Kein Broadcast mehr. Macht ja auch Sinn ...angehackt
Oha, so brachial solltest du aber auch keinesfalls vorgehen!!https://de.wikipedia.org/wiki/Hacke_(Werkzeug)
https://de.wikipedia.org/wiki/Ferse
Du solltest lediglich einen Haken sanft anklicken.
wie der DHCRelay Dienst überhaupt dazu kommt zu reagieren. Wenn der Client ein Paket direkt an den Server sendet
Sehr gute Frage und ganz sicher ein Fehler im Relay Service der OPNsense, denn entsprechende Layer 3 Switches tun dies nachweislich bei aktivem Relay nicht. Müsste man glatt mal bei der pfSense testen wie die sich hier verhält?!der Debian-Client sendet nur noch eine Unicast Anfrage direkt an den Server.
Macht Winblows, wie man oben sieht, ja auch und übrigens MacOS auch.
Ich hätte aber nie gedacht, dass ausgerechnet du Netzwerke mit Windows testest
So nach meiner Vorstellung hätte ich schon gedacht, dass du mindestens Archlinux mit selber kompiliertem Kernel hast.
Haken oder Hacken, ist das nicht freie Meinungsäusserung ? Woke? Inklusion oder sonst was ?
So nach meiner Vorstellung hätte ich schon gedacht, dass du mindestens Archlinux mit selber kompiliertem Kernel hast.
Haken oder Hacken, ist das nicht freie Meinungsäusserung ? Woke? Inklusion oder sonst was ?
1hab ich nicht angehackt
@aqui, das kommt nicht von "Hacke", das kommt von "hacken". Die Jungs hier sehen sich als Hacker in der positiven Grundbedeutung, ergo ist alles, was sie am PC machen "hacken", auch das setzen eines Häkchens (einige machen ja auch gar nichts anderes
)Das ist jedenfalls meine Erklärung dafür, dass das hier in praktisch jedem dritten Fred nicht ganz rechtschreibkonform auftaucht.
Schon schwieriger zu ergründen war die "Musse"
... hatte ich nicht die Musse das weiter zu verfolgen.
Das halte ich eher für eine Reminiszenz and den heutigen Nachtisch den man allerdings auch etwas anders schreiben würde, aber Shwam drüber Spaß beiseite,
da nun klar ist, dass das Unicast ist, ist das schon eine bemerkenswerte Schludrigkeit auf der Sense. Da hat jemand den folgenden Satz aus der Doku wohl etwas undifferenziert in Code umgesetzt:
DHCP relaying is the forwarding of DHCP requests received on one interface to the DHCP server of another.
Die Anfrage des Clients wird ja am Interface der Sense geroutet. Dabei scheint sich dann auch das Relay angesprochen zu fühlen.Meldet das einer von Euch? Hans, der Entdecker? Wer eine Sense nutzt, ist ja der Community verpflichtet
Vielleicht gibt ja die Meldung noch eine rationale Erklärung dafür. Zu sehen vermag ich sie nicht. Wie ich den Kollegen @aqui kenne, hat er schon die PfSense angeworfen
Viele Grüße, commodity
Die noch nicht aber einen Cisco Catalysten!
Dort sieht das Verhalten entsprechend standardkonform aus:
Clientseite:
(Der "Discover" Frame kam weil der Winblows Testlaptop kein Netzteil angeschlossen hatte und in den Standby gegangen ist. )
Serverseite:
De facto also etwas kaputt auf OPNsense Seite mit dem Relay.
Wer checkt die pfSense?? 😉
Dort sieht das Verhalten entsprechend standardkonform aus:
Clientseite:
)Serverseite:
De facto also etwas kaputt auf OPNsense Seite mit dem Relay.
Wer checkt die pfSense?? 😉
Eine pfSense hab ich leider nicht.
Aber ich würde sonst auf jeden Fall im OPNsense Forum einen Beitrag erstellen, mit Verweis auf hier.
Aber ich würde sonst auf jeden Fall im OPNsense Forum einen Beitrag erstellen, mit Verweis auf hier.
1
Das wäre sicher sehr hilfreich, denn es ist definitiv ein Bug im aktuellen Release bzw. der Relay Funktioin! 👍
Aber ich würde sonst auf jeden Fall im OPNsense Forum einen Beitrag erstellen, mit Verweis auf hier.
+1Ich habe auch eine PfSense, aber derzeit keine Zeit.
Viele Grüße, commodity
Hier gemeldet: https://forum.opnsense.org/index.php?topic=40720.0
Ich hab mir mal für unsere interne Dokumentation diese Sequenzdiagramme erstellt.
Vielleicht mag sie mal jemand anschauen, ob sie stimmen.
DHCP Handshake beim Booten im gleichen Netzsegment:
https://sequencediagram.org/index.html#initialData=MQFwliA2CmAEAiAJAwgBV ...
DHCP Renewal in beliebigem Netzwerksegment (Das funktioniert so bei OPNsense nicht):
https://sequencediagram.org/index.html#initialData=MQFwliA2CmAEAiAJAwgBV ...
DHCP Handshake mit Relay beim Booten:
https://sequencediagram.org/index.html#initialData=MQFwliA2CmAEAiAJAwgBV ...
Vielleicht mag sie mal jemand anschauen, ob sie stimmen.
DHCP Handshake beim Booten im gleichen Netzsegment:
https://sequencediagram.org/index.html#initialData=MQFwliA2CmAEAiAJAwgBV ...
DHCP Renewal in beliebigem Netzwerksegment (Das funktioniert so bei OPNsense nicht):
https://sequencediagram.org/index.html#initialData=MQFwliA2CmAEAiAJAwgBV ...
DHCP Handshake mit Relay beim Booten:
https://sequencediagram.org/index.html#initialData=MQFwliA2CmAEAiAJAwgBV ...
Sieht gut aus! 👍
pfSense 2.7.2 zeigt dasselbe Verhalten.
In der Mailinglist von ISC habe ich in einem ganz alten Beitrag gelesen, dass dies das normale Verhalten des Relays wäre:
https://lists.isc.org/pipermail/dhcp-users/2015-September/019218.html
Seid ihr sicher, dass dies vor einiger Zeit wirklich anders war?
Der obige Beitrag schlägt die Option "-m discard" vor.
In der Manpage steht dazu:
(https://man.freebsd.org/cgi/man.cgi?query=dhcrelay)
In der Mailinglist von ISC habe ich in einem ganz alten Beitrag gelesen, dass dies das normale Verhalten des Relays wäre:
https://lists.isc.org/pipermail/dhcp-users/2015-September/019218.html
Seid ihr sicher, dass dies vor einiger Zeit wirklich anders war?
Der obige Beitrag schlägt die Option "-m discard" vor.
In der Manpage steht dazu:
-m append|replace|forward|discard
Control the handling of incoming DHCPv4 packets which already
contain relay agent options. If such a packet does not have gi-
addr set in its header, the DHCP standard requires that the
packet be discarded. However, if giaddr is set, the relay agent
may handle the situation in four ways: It may append its own
set of relay options to the packet, leaving the supplied option
field intact; it may replace the existing agent option field; it
may forward the packet unchanged; or, it may discard it.pfSense 2.7.2 zeigt dasselbe Verhalten.
Danke fürs Testen! 👍dass dies vor einiger Zeit wirklich anders war?
Nein, weil das wohl auch niemandem so im Detail aufgefallen ist.De facto kann man es aber mit den diversen Switch und Router Herstellern vergleichen die DHCP Relay supporten auf ihren Produkten und wo es nachweisbar NICHT so ist. Siehe Verhalten von Cisco und Ruckus oben. Hier passiert die Kommunikations ja erwartungsgemäß direkt als Unicast zw. Client und DHCP Server.
Die Info mit dem Relay Agent ist interessant. Kollege @HansFenner meinte aber das das Verhalten keinen Unterschied macht ob das in der OPNsense gesetzt ist oder nicht.
Ich hatte es ohne den Agent Haken getestet.
Dennoch erklärt es nicht hinreichend warum das Firewall Interface selber aktiv sowohl einen Request an den Server und auch ein ACK an den Client schickt obwohl es außer der Forwarding/Relay Funktion direkt zum Server NICHT am DHCP Prozess beteiligt sein sollte.
Auch warum es nur im halbstündlichen Keepalive passiert nicht aber nach einem Kaltstart oder Booten zeigt eher das da etwas zumindestens unsauber ist.
Habe jetzt mal mit dem Paramter -m discard getestet, macht aber bei mir leider keinen Unterschied.
Nur beim Renew schickt der Client Unicasts direkt an den Server! Dabei geschieht dann die "Paket-Verdoppelung" weil der Relay aus diesen Unicasts nochmal zusätzliche Pakete erstellt und zum Server schickt.
Definitiv ein anderes Verhalten als bei Switchen, aber möglicherweise von ISC tatsächlich so vorgesehen(?)...
Um beim Debuggen nicht verrückt zu werden, habe ich bei mir jetzt vorerst die DHCP-Unicasts von den Client-Netzen zum DHCP-Server per Firewall blockiert. Somit sehe ich am Server nur noch die Renews vom Relay... und alles funktioniert ;)
Auch warum es nur im halbstündlichen Keepalive passiert nicht aber nach einem Kaltstart oder Booten zeigt eher das da etwas zumindestens unsauber ist.
Nach einen Kaltstart bzw. Release+Renew schickt der Client ausschließlich Broadcasts. Daraus macht der Relay Unicasts zum DHCP-Server, welche dort genau 1x ankommen.Nur beim Renew schickt der Client Unicasts direkt an den Server! Dabei geschieht dann die "Paket-Verdoppelung" weil der Relay aus diesen Unicasts nochmal zusätzliche Pakete erstellt und zum Server schickt.
Definitiv ein anderes Verhalten als bei Switchen, aber möglicherweise von ISC tatsächlich so vorgesehen(?)...
Um beim Debuggen nicht verrückt zu werden, habe ich bei mir jetzt vorerst die DHCP-Unicasts von den Client-Netzen zum DHCP-Server per Firewall blockiert. Somit sehe ich am Server nur noch die Renews vom Relay... und alles funktioniert ;)
Nur beim Renew schickt der Client Unicasts direkt an den Server!
Richtig! Bestätigt dann auch die Erkenntnisse des hiesigen Threads! aber möglicherweise von ISC tatsächlich so vorgesehen
Genau das ist die entscheidende Frage...!Fällt allerdings schwer die Logik dahinter dann zu verstehen, denn das Verhalten ist eigentlich sinnfrei.
Um beim Debuggen nicht verrückt zu werden
Das muss man auch gar nicht...Am Client reicht es den Wireshark zu starten mit einem Capture Filter auf Port 67 und 68
Parallel dazu lässt man am DHCP Server mit tcpdump -i <interface> -s 65535 -w dhcpservercapture.pcap laufen.
Die Datei dhcpservercapture.pcap kann man dann ganz entspannt in den Wireshark laden und so die Serverseite im Vergleich betrachten.
Sehr interessant, insbesondere der Link zur Mailing-List.
Den Hinweis auf den Parameter -m verstehe ich nicht, denn dort geht es ja nur um "... the handling of incoming DHCPv4 packets which already contain relay agent options." Der DHCP-Request des Clients sollte solche Options doch gar nicht enthalten. Relay Agent Options sind IMO nur im Verhältnis Relay <-> Server relevant, wie auch zum Parameter -a erläutert, wo steht, dass die Options für Pakete vom Relay zum Client wieder "stripped" werden.
Im Ergebnis klingt die Mail für mich so, als ob das Verhalten einer Interpretation des (so verstandenen) ISC-Standards folgt und die Sense-Entwickler gar keinen Einfluss darauf gehabt hätten.
Auch das verstehe ich nicht, denn das Relay muss ja den direkt an den Server gerichteten Request des Clients konkret verarbeiten (statt nur zu routen), was es im Übrigen überhaupt nur kann, wenn es zugleich auch Router ist. Der Client weiß vom Relay doch überhaupt nichts.
Dieser Verarbeitungsvorgang kann auch nicht dem ISC-DHCP-Server zuregerechnet werden, er findet doch allein auf der Sense statt. Für mich ist das ein Bug. Lustig aber, dass das offenbar schon seit mindestens 9 Jahren so ist und es kaum jemand bemerkt hat.
Viele Grüße, commodity
Den Hinweis auf den Parameter -m verstehe ich nicht, denn dort geht es ja nur um "... the handling of incoming DHCPv4 packets which already contain relay agent options." Der DHCP-Request des Clients sollte solche Options doch gar nicht enthalten. Relay Agent Options sind IMO nur im Verhältnis Relay <-> Server relevant, wie auch zum Parameter -a erläutert, wo steht, dass die Options für Pakete vom Relay zum Client wieder "stripped" werden.
Im Ergebnis klingt die Mail für mich so, als ob das Verhalten einer Interpretation des (so verstandenen) ISC-Standards folgt und die Sense-Entwickler gar keinen Einfluss darauf gehabt hätten.
Auch das verstehe ich nicht, denn das Relay muss ja den direkt an den Server gerichteten Request des Clients konkret verarbeiten (statt nur zu routen), was es im Übrigen überhaupt nur kann, wenn es zugleich auch Router ist. Der Client weiß vom Relay doch überhaupt nichts.
Dieser Verarbeitungsvorgang kann auch nicht dem ISC-DHCP-Server zuregerechnet werden, er findet doch allein auf der Sense statt. Für mich ist das ein Bug. Lustig aber, dass das offenbar schon seit mindestens 9 Jahren so ist und es kaum jemand bemerkt hat.
Viele Grüße, commodity
1
Das mit den Relay Optionen hab ich so verstanden, das man dies nur braucht, wenn mehrere Relays im Spiel sind, z.B. in einer Kaskade. Auf jeden Fall hat es keinen Einfluss auf das Problem m.M.n..
Aktuell bin ich mit DHCPv6 und Relay am basteln. Hier ist es noch viel schlimmer.
Aktuell hab ich diesen Stand:
Der Client sendet ein Solicit.
Das Relay empfängt den Solicit und verdoppelt ihn
Der Kea DHCPv6 Server empfängt 2 Relay-Fwd Solicits
Jetzt wird schon schlimmer:
Der Kea DHCPv6 Server sendet 2 Relay-Reply Advertise. Leider mit 2 verschiedenen dynamischen Client-IPs
Und noch schlimmer:
Was jetzt passiert, weiss ich noch nicht. Der Client bekommt nie eine Antwort vom Relay.
Ich bin noch ein bisschen am testen und protokollieren.
Wenn aber jemand Lust hat, auf der OPNsense zu testen, ob DHCPv6 mit Relay funktioniert, bin ich natürlich dankbar. Es ist ja Freitag, der Tag des Mitleids mit den Armen
Aktuell bin ich mit DHCPv6 und Relay am basteln. Hier ist es noch viel schlimmer.
Aktuell hab ich diesen Stand:
Der Client sendet ein Solicit.
Das Relay empfängt den Solicit und verdoppelt ihn
Der Kea DHCPv6 Server empfängt 2 Relay-Fwd Solicits
Jetzt wird schon schlimmer:
Der Kea DHCPv6 Server sendet 2 Relay-Reply Advertise. Leider mit 2 verschiedenen dynamischen Client-IPs
Und noch schlimmer:
Was jetzt passiert, weiss ich noch nicht. Der Client bekommt nie eine Antwort vom Relay.
Ich bin noch ein bisschen am testen und protokollieren.
Wenn aber jemand Lust hat, auf der OPNsense zu testen, ob DHCPv6 mit Relay funktioniert, bin ich natürlich dankbar. Es ist ja Freitag, der Tag des Mitleids mit den Armen
Aber dann haben wir zumindestens was zum Testen am Wochenende. Also: Auf zu DHCPv6 mit Relay!
Einfach nochmal meine Umgebung auf der OPNsense erklärt:
- Ich hab verschiedene Schnittstellen und VLANs konfiguriert.
- DHCPv6 ist auf allen Schnittstellen deaktiviert.
- Bei allen Schnittstellen ist 'Manuelle Konfiguration' aktiviert (ganz unten, letzte Option)
- Bei allen Schnittstellen ist RA auf 'assistiert', also mit den Flags A, M, O
- Der externe Kea DHCPv6 Server ist im VLAN50.
- Bei allen Schnittstellen ist DHCRelay konfiguriert, ausser VLAN50, dort braucht man das nicht, weil dort der Kea DHCPv6 Server selber sitzt.
Wie oben bereits beschrieben, senden alle Clients SOLICIT Messages ab. Die kommen auch am Relay an und werden weitergeleitet. Sie kommen auch am DHCP-Server an und werden beantwortet. Danach versandet das Ganze.
Noch viel verrückter:
Dass am DHCP Server nun ebenfalls 2 (zwei) Relay-forw Solicits pro Client eintreffen, bin ich ja schon gewohnt. Die beiden werden auch mit je einem Relay-reply Advertise beantwortet.
Auf dem Testclient (VLAN11) erhalte ich nun aber ebenfalls sämtliche Solicits Mitteilungen aller Clients im gesamten Netz (also alle VLANs) und zwar von der Gateway Link Local Adresse fe80::xxxx (also von der OPNsense) an die Gruppe ff02::1:2 und diese natürlich auch immer doppelt.
Jetzt muss ich also davon ausgehen, dass das Relay nicht nur doppelt an den DHCPv6-Server sendet, sondern auch noch an alle konfigurierten Schnittstellen an die Gruppe ff02::1:2.
Das alles macht vollkommen keinen Sinn.
- Ich hab verschiedene Schnittstellen und VLANs konfiguriert.
- DHCPv6 ist auf allen Schnittstellen deaktiviert.
- Bei allen Schnittstellen ist 'Manuelle Konfiguration' aktiviert (ganz unten, letzte Option)
- Bei allen Schnittstellen ist RA auf 'assistiert', also mit den Flags A, M, O
- Der externe Kea DHCPv6 Server ist im VLAN50.
- Bei allen Schnittstellen ist DHCRelay konfiguriert, ausser VLAN50, dort braucht man das nicht, weil dort der Kea DHCPv6 Server selber sitzt.
Wie oben bereits beschrieben, senden alle Clients SOLICIT Messages ab. Die kommen auch am Relay an und werden weitergeleitet. Sie kommen auch am DHCP-Server an und werden beantwortet. Danach versandet das Ganze.
Noch viel verrückter:
Dass am DHCP Server nun ebenfalls 2 (zwei) Relay-forw Solicits pro Client eintreffen, bin ich ja schon gewohnt. Die beiden werden auch mit je einem Relay-reply Advertise beantwortet.
Auf dem Testclient (VLAN11) erhalte ich nun aber ebenfalls sämtliche Solicits Mitteilungen aller Clients im gesamten Netz (also alle VLANs) und zwar von der Gateway Link Local Adresse fe80::xxxx (also von der OPNsense) an die Gruppe ff02::1:2 und diese natürlich auch immer doppelt.
Jetzt muss ich also davon ausgehen, dass das Relay nicht nur doppelt an den DHCPv6-Server sendet, sondern auch noch an alle konfigurierten Schnittstellen an die Gruppe ff02::1:2.
Das alles macht vollkommen keinen Sinn.
...und zeigt das die Relay Funktion für beide Protokollvarianten ziemlich kaputt ist!
Ich checke auch das v6 Verhalten mal bei einem Cisco...
Ich checke auch das v6 Verhalten mal bei einem Cisco...
Also ich bin nun auch nach vielen weiteren Tests und ein paar eigenen Installationen von dhcrelay zum Schluss gekommen, dass dieses Produkt nicht so funktioniert, wie es soll.
Erstaunlich natürlich, dass es den Weg in die OPNsense gefunden hat.
Ich werde momentan da keine Zeit mehr verplempern und danke allen, die sich dem Problem angenommen haben.
Erstaunlich natürlich, dass es den Weg in die OPNsense gefunden hat.
Ich werde momentan da keine Zeit mehr verplempern und danke allen, die sich dem Problem angenommen haben.
Danke Dir für eine wirklich interessante Feststellung
Zumindest können wir fest halten:
Viele Grüße, commodity
Zumindest können wir fest halten:
- es funktioniert (was vielen reicht)
- es sollte der Sicherheit nicht abträglich sein (was gut ist)
- für den anspruchsvolleren Netzwerker bleibt ein schaler Beigeschmack
Viele Grüße, commodity
1
Ein Kurztest mit Cisco L3 Switch (Sowohl Catalyst als auch CBS), Cisco Router und einem Mikrotik (RouterOS) zeigt auch bei v6 das korrekte und erwartbare Verhalten wie schon bei v4.
Ist wohl echt ein kosmetisches Problem in der OPNsense Relay Funktion und sollte man ggf. mal als Bugreport direkt an OPNsense / Deciso melden.
Beeinträchtigend ist es aber nicht, denn die Relay Funktion ist ja letztlich gegeben. Sicherlich auch ein Hauptgrund warum es wohl niemanden bis dato aufgefallen ist, denn wer troubleshooted eine an sich korrekt arbeitende Funktion auch wenn sie Zicken macht?!
Ist wohl echt ein kosmetisches Problem in der OPNsense Relay Funktion und sollte man ggf. mal als Bugreport direkt an OPNsense / Deciso melden.
Beeinträchtigend ist es aber nicht, denn die Relay Funktion ist ja letztlich gegeben. Sicherlich auch ein Hauptgrund warum es wohl niemanden bis dato aufgefallen ist, denn wer troubleshooted eine an sich korrekt arbeitende Funktion auch wenn sie Zicken macht?!
wer troubleshooted eine an sich korrekt arbeitende Funktion
Z.B. der fortgeschrittene Netzwerker, der es liebt, abends statt des Tatorts, den Trace seiner Firewall zu betrachten! Gibt ja andere hier, die sogar gleich ein dickes Fass aufmachen, weil sie ein paar mehr Portscans bei sich entdeckt haben.
Viele Grüße, commodity
Also nochmal: Es funktioniert nur mit IPv4.
Mit IPv6 funktioniert das Relay auf der OPNsense nicht mehr. Es gibt schon Gründe, warum alle anderen Hersteller die Relay Funktion richtig implementiert haben.
Aber ISC Dhcrelay ist eh EOL. Es wird Zeit, dass man da nach Alternativen sucht.
Mit IPv6 funktioniert das Relay auf der OPNsense nicht mehr. Es gibt schon Gründe, warum alle anderen Hersteller die Relay Funktion richtig implementiert haben.
Aber ISC Dhcrelay ist eh EOL. Es wird Zeit, dass man da nach Alternativen sucht.
1
