DHCPv4 am vLan gibt keine Adresse raus

Started by kruemelmonster, September 15, 2021, 04:56:38 PM

Previous topic - Next topic
September 15, 2021, 04:56:38 PM Last Edit: September 15, 2021, 05:19:09 PM by kruemelmonster
Hallo allerseits,

ich habe auf meiner Opnsense einige vLans eingerichtet. Teilweise gehören zu denen auch Wlan's (über einen Unifi-AP) dazu:

vlan_8 ohne dhcp
vlan_9 (nur zum administrieren des UniFi-UAP)
vlan_18 mit WLAN, mit dhcp
vlan_23 mit dhcp
vlan_28 mit WLAN, mit dhcp
vlan_33 mit dhcp

Heute wollte ich mich mit einem Gerät in das WLAN am vlan 18 einklinken. WLAN als solches geht, aber das Gerät bekommt ums Verrecken keine IP-Adresse vom dhcp-Server. Auf dem UAP sind die Wlan's und die darunter liegenden vlans bis auf ssid, key und vlan-id identisch eingerichtet. Im Übrigen erfolgt die Adressvergabe ausschließlich über die opnsense. Im vlan_28, in dem die Funktelefone der Familie hängen klappt es dagegen ohne Probleme. Auch alle anderen Netze verteilen brav Adressen.

Habe in var/log/dhcpd.log Einträge der folgenden Art gefunden:
lease 192.168.18.200: no subnet

Hat jemand einen Tipp, wie ich das hinbekomme? Kann ich da ggf. auch was über die Shell machen? Auf dem GUI ist da nichts zu machen; zumindest habe ich da nichts brauchbares herausgefunden.

Gruß Kruemelmonster
Mini-PC; Celeron N5105; 16GB RAM; 4 x i226

Hat die OPNSense in dem VLAN eine IP-Adresse?
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Ja, hat sie. In dem Fall die 192.168.18.1. das ist nict das problem. Auf dem GUI sehen alle Angaben bei dem 18-er Subnetz genau so aus wie beim funktionierenden 28-er Subnetz.
Mini-PC; Celeron N5105; 16GB RAM; 4 x i226

Dann würde ich mir als nächstes angucken, was das UI denn an Konfiguration für den dhcpd generiert und ob dort vielleicht irgendetwas schräg ist. Das ist diese Datei hier:
/var/dhcpd/etc/dhcpd.conf
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Nein, da ist nichts Auffälliges drin.

Hier mal ein Auszug von den rumzickenden Subnetz:
subnet 192.168.18.0 netmask 255.255.255.0 {
  pool {
    range 192.168.18.200 192.168.18.250;
  }

  option routers 192.168.18.1;
  option domain-name-servers 192.168.18.1;

}

Und zum Vergleich das funktionierende Subnetz:
subnet 192.168.28.0 netmask 255.255.255.0 {
  pool {
    range 192.168.28.200 192.168.28.250;
  }

  option routers 192.168.28.1;
  option domain-name-servers 192.168.28.1;

}

host s_opt2_0 {
  hardware ethernet a0:a0:a0:a0:a0:a0;
  fixed-address 192.168.28.200;
}
Mini-PC; Celeron N5105; 16GB RAM; 4 x i226

Statische Adressen sollten außerhalb der dynamischen "range" liegen ...
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Danke für den Hinweis. Habe es entsprechend angepasst.
Mini-PC; Celeron N5105; 16GB RAM; 4 x i226

Hallo pmhausen,

danke für die Tips. Habe eben den Fehler gefunden. Typischer Fall von Selbstüberlistung. In der OpnSense war alles richtig. Aber wenn man dem Switchport die notwendigen Tagging-Einträge für den Port mit dem UAP dran vorenthält...

Mal eine Frage zu deinem Hinweis mit den Reservierungen. Ich dachte, dhcp kann Adressen ausschließlich aus dem freigegebenen Bereich vergeben? Deshalb hatte ich dieselben auch dort eingetragen.

Gruß Krümelmonster
Mini-PC; Celeron N5105; 16GB RAM; 4 x i226

Der ISC dhcpd unterscheidet zwischen Subnet, Dynamischem Bereich und festen Reservierungen. Der Bereich und die Reservierungen müssen im Subnet liegen, sollten sich aber nicht überschneiden. Sonst kann es zu doppelt vergebenen Adressen kommen.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Wobei er das inzwischen m.W. gelernt hat. Also mit Reservierungen im Pool umgehen kann und diese entsprechend bei der dynamischen Vergabe ausschließt. Wir hatten dazu mal eine Sperre in der UI damit man das gerade nicht machen konnte. Die wurde aber IMHO rausgenommen nachdem wir nachgelesen hatten, dass der DHCPd inzwischen damit wohl sauber umgehen kann :)

Ich würde immer noch dazu raten, wie @pmhausen, dass man die Bereiche nichts mischt - macht Debugging einfacher - aber es geht wohl inzwischen gut wenn man's tut ;)

Cheers
\jens
"It doesn't work!" is no valid error description! - Don't forget to [applaud] those offering time & brainpower to help you!
Better have some *sense as no(n)sense! ;)

If you're interested in german-speaking business support, feel free to reach out via PM.