Messages

Also ich hab nun noch ein paar weitere Tests gemacht und bin zum Schluss gekommen, dass der Fehler wirklich bei dhcrelay liegt.

Der Dienst lässt sich ausschliesslich nur an ein Interface binden. Es fehlt schlichtweg an weiteren Optionen. Dann schnappt er sich alles, was über den Port 68 (DHCP) läuft und leitet es weiter. Damit leitet er auch unicast Mitteilungen weiter, womit es zum bekannten Problem kommt.

Richtig wäre, wenn er nur auf die Broadcast Adresse hören würde. Keine Ahnung, was sich ISC dabei gedacht hat.

Nun ist es aber eh so, dass dhcrelay EOL ist und man sich nach einer Alternative umschauen sollte. ISC bietet aktuell mit Kea kein Relay an und es ist unklar, ob dies je mal kommt.

Hier hab ich auf die Schnelle einen Beitrag zu Alternativen gefunden:
https://vyos.dev/T6256

[ps -auxw | grep dhcp]

Ich hab nie behauptet, dass der Fehler bei OPNsense liegt.

Ich stelle nur fest, dass die Relay Funktion fehlerhaft ist, bzw. bei IPv6 gar nicht geht.

Ich hab heute mal folgendes gemacht:

1. Alle DHCRelay Dienste (IPv4) auf der OPNsense deaktiviert. Mit ps -auxw | grep dhcp kontrolliert. Läuft nichts mehr.

2. Auf der Konsole den Dienst manuell mit /usr/local/sbin/dhcrelay -d -i vlan0.1.5 192.168.50.56
aufgerufen.

Jetzt sieht man auf der Konsole Meldungen vom Relay. Und da sind zumindest keine doppelten Einträge zu sehen. Das Log kann natürlich aber auch lügen :) Mit tcpdump sieht man aber trotzdem den unlogischen Verkehr mit den mehrfachen Messages.

Danach hab ich noch einen weiteren Test gemacht:
Eine weitere VM im VLAN10 aufgesetzt und isc-dhcp-relay installiert. Danach funktioniert im VLAN10 alles einwandfrei. Keine doppelten Anfragen und Requests mehr.

Bloss dieser Test ist gar nicht relevant. Mein selber aufgesetztes Relay bekommt nur 1x etwas zu arbeiten, nämlich wenn meine Testclient-VM im VLAN10 bootet. Nur dann sendet sie ein DISCOVER auf die Broadcastadresse. Und nur dann nimmt das Relay auf der anderen VM im VLAN10 die Anfrage überhaupt entgegen und leitet sie auch weiter.

Alle anderen Renewal Requests vom Client sind unicast. Sie gehen direkt vom Client an den Server. Das Relay bekommt davon gar nichts mit.

Ich denke, genau da liegt der Hund begraben. Warum wird eine Unicast Anfrage auf der OPNsense vom Relay empfangen und beantwortet?

Also ich kann mir nicht vorstellen, dass sich ISCRelay so komisch verhält. Das alles sind sehr alte Protokolle und sollten eigentlich genügend getestet sein. Ich kenne auch kein anderes Gerät, dass sich so verhält.

Mittlerweile hab ich vertieft das Relay auch mit IPv6 getestet und krieg es gar nicht zum Laufen, bzw. es macht verrückte Sachen.
https://administrator.de/forum/opnsense-dhcp-mit-relay-immer-2x-request-2-ack-und-2-leases-1589798666.html?token=100#comment-23250453326

Ich würde vermuten, der Dienst ist falsch an Schnittstellen gebunden. So wie ich gesehen habe, hat DHCRelay keine Konfigurationsdatei, sondern wird nur mit Optionen aufgerufen.

Ich habe diesen Dienst nie selber installiert, da es ausserhalb eines Routers dafür keine Verwendung gibt. Ich kenne ihn also nicht.

Ich würde auch behaupten, dass dieses Problem schon letztes Jahr als ich mit der OPNSense zum ersten Mal angefangen habe, bestanden hat.

Hallo zusammen,

Ich betreibe einen externen Kea DHCP-Server und benutze auf der OPENsense den DHCRelay Dienst.

Ein Relay sollte eigentlich nur eine Weiterleitung machen, wenn es auf der Broadcast-Adresse angesprochen wird. Z.B. bei einem DHCP-Discovery.

Ist einem Client die DHCP-Adresse des DHCP-Servers einmal bekannt, spricht der Client den Server Unicast direkt an.

Der Fehler bei OPENsense ist, dass auch im letzteren Fall das Relay alle weiteren Mitteilungen wie REQUEST oder RELEASE kopiert und ebenfalls an den Server weiterleitet. Damit kommen alle Anfragen beim Server doppelt an, womit dieser beispielsweise auch 2x einen Lease vergibt.

Die ganze Geschichte mit Beispielen findet man hier und der Bug wurde dort bestätigt:

https://administrator.de/forum/opnsense-dhcp-mit-relay-immer-2x-request-2-ack-und-2-leases-1589798666.html