[SOLVED] DHCP-Server funktioniert nicht in VMs

[Scuruba]

Hallo zusammen,

ich habe seit einigen Wochen einen Intel NUC 11 Gen. (BNUC11TNHV50L00) mit Proxmox VE am laufen. Plan ist es hier einige kleinere VMs, sowie OPNsense als Firewall für mein Netzwerk laufen zu lassen. Nach einigen Anfangsschwierigkeiten wegen der zwei Intel Ethernet Controller i225-LM welche nicht vom alten Kernel unterstützt werden, läuft das ganze nun recht gut. Installiert ist zur Zeit der Kernel 5.11 womit die NICs anscheinend auch laufen.
Mein Problem welches ich nicht in den Griff bekomme ist, dass zwar anscheinend das meiste funktioniert, aber eben nicht alles. Am meisten macht mir der nicht funktionierende DHCP-Server zu schaffen.
Ich kann den DHCP-Server (egal welcher) zwar starten, aber im Netzwerk bekommen die Geräte keine IP-Adresse. Manche Geräte werden war in den Leases eingetragen aber es tut sich eben auf den Geräte nichts. Auch ein Neustart der Geräte ändert nichts an diesem Zustand.

Der DHCP-Server im alten Router, sowie auf dem Raspberry funktionieren (abwechselnd natürlich), aber eben nicht virtuell. Weder in OPNsense als VM mit BSD, noch als VM mit Ubuntu oder als CT mit Debian oder Ubuntu. Auch habe ich mehrere Server ausprobiert wie DNSmasq, ISC-DHCP den integrierten des PiHole und halt den in der OPNsense.
Nebenbei bekomme ich in Homeassistant weder den AppleTV, noch meinen AVR-Reciver eingebunden was auch hier über den Pi problemlos funktioniert. Aber das nur am Rande. Ich vermute es ist auf das selbe problem zurückzuführen, lässt sich am DHCP-Server aber natürlich besser nachstellen.

Um die NICs als Fehlerquelle auszuschließen habe ich auch einen USB 3 - Ethernetadapter ausprobiert (Irgendein Realtek, ist aber schon älter) aber auch hier das selbe. Viele von euch haben es nach meiner Recherche ja geschafft mit OPNsense und DHCP-Server sowie auch mit HomeAssistant VM, also ist es ja anscheinend möglich.

Hier mal ein paar Infos aus Proxmox:
(ein Netzwerkkabel am USB-Adapter war währenddessen nicht angeschlossen, sondern an LAN NIC)

Spoiler: brctl show

bridge name bridge id STP enabled interfaces
vmbr0 8000.54b2039edcf1 no enp88s0
veth104i0
vmbr1 8000.00e04c9808ca no enx00e04c9808ca
vmbr2 8000.54b2039eddc3 no enp89s0

Spoiler: journalctl -u networking.service

-- Logs begin at Wed 2021-05-12 20:55:45 CEST, end at Thu 2021-05-13 12:16:00 CEST. --
May 12 20:55:46 pve systemd[1]: Starting Network initialization...
May 12 20:55:46 pve networking[901]: networking: Configuring network interfaces
May 12 20:55:47 pve systemd[1]: Started Network initialization.

Spoiler: cat /etc/network/interfaces

auto lo

iface lo inet loopback

iface enp89s0 inet manual
#NIC unten

iface enx00e04c9808ca inet manual
#NIC USB

iface enp88s0 inet manual
#NIC oben

auto vmbr1
iface vmbr1 inet manual
bridge-ports enx00e04c9808ca
bridge-stp off
bridge-fd 0
#USB

auto vmbr2
iface vmbr2 inet manual
bridge-ports enp89s0
bridge-stp off
bridge-fd 0
#WAN

auto vmbr0
iface vmbr0 inet static
address 192.168.0.8/24
gateway 192.168.0.10
bridge-ports enp88s0
bridge-stp off
bridge-fd 0
network 192.168.0.0
boadcast 192.168.0.255
#LAN

Spoiler: Paketversionen

proxmox-ve: 6.4-1 (running kernel: 5.11.17-1-pve)
pve-manager: 6.4-6 (running version: 6.4-6/be2fa32c)
pve-kernel-5.11: 7.0-1~bpo10
pve-kernel-5.4: 6.4-2
pve-kernel-helper: 6.4-2
pve-kernel-5.11.17-1-pve: 5.11.17-1~bpo10
pve-kernel-5.11.7-1-pve: 5.11.7-1~bpo10
pve-kernel-5.4.114-1-pve: 5.4.114-1
pve-kernel-5.4.73-1-pve: 5.4.73-1
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.1.2-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: not correctly installed
ifupdown2: 3.0.0-1+pve3
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.20-pve1
libproxmox-acme-perl: 1.1.0
libproxmox-backup-qemu0: 1.0.3-1
libpve-access-control: 6.4-1
libpve-apiclient-perl: 3.1-3
libpve-common-perl: 6.4-3
libpve-guest-common-perl: 3.1-5
libpve-http-server-perl: 3.2-2
libpve-storage-perl: 6.4-1
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.6-2
lxcfs: 4.0.6-pve1
novnc-pve: 1.1.0-1
openvswitch-switch: 2.12.3-1
proxmox-backup-client: 1.1.7-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.5-4
pve-cluster: 6.4-1
pve-container: 3.3-5
pve-docs: 6.4-2
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-3
pve-firmware: 3.2-3
pve-ha-manager: 3.1-1
pve-i18n: 2.3-1
pve-qemu-kvm: 5.2.0-6
pve-xtermjs: 4.7.0-3
qemu-server: 6.4-2
smartmontools: 7.2-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 2.0.4-pve1

Leider sind mir die Ideen ausgegangen, wie ich hier weiter vorgehen soll oder wie ich den Fehler weiter eingrenzen kann, daher hoffe ich das jemand von euch mir weiterhelfen kann.
Schon einmal schönen Dank dafür.

 

[ph0x]

Läuft der DHCP in einer VM? Wenn ja, werden die zwei Bridges als WAN und LAN reingereicht oder wie sieht die Konfiguration aus?
Auf welcher Bridge sollen DHCP-Leases verteilt werden?
Läuft die Proxmox-Firewall bei einer der beteiligten VMs?

 

[Scuruba]

Läuft der DHCP in einer VM? Wenn ja, werden die zwei Bridges als WAN und LAN reingereicht oder wie sieht die Konfiguration aus?

Die LAN Bridge (vmbr0) wird allen VMs und CTs zugeteilt, mit fester IP und Gateway in Proxmox. Die WAN (vmbr1) Bridge wird nur der OPNsense zugeteilt.

Auf welcher Bridge sollen DHCP-Leases verteilt werden?

Auf der LAN Bridge (vmbr0)

Läuft die Proxmox-Firewall bei einer der beteiligten VMs?

Nein die habe ich noch komplett deaktiviert, um Fehler hierdurch auszuschließen.

 

[ph0x]

Die LAN Bridge (vmbr0) wird allen VMs und CTs zugeteilt, mit fester IP und Gateway in Proxmox.

Was meinst du mit dem letzten Satz? Damit hat zwar dein Host eine IP und ein Gateway, für die VMs ist das aber unerheblich, es sei denn, du verteilst dieselben Informationen auch über den DHCP.
Welche Adresse hat denn die Sense-VM? Ist dort auch das DHCP-Plugin aktiviert? Und sind die anderen VMs so konfiguriert, dass sie einen DHCP suchen, ja?

 

[Scuruba]

Vielleicht habe ich mich schlecht ausgedrückt.
Ziel ist es mit dem NUC und den zwei Schnittstellen eine Firewall aufzubauen, nur eben in Proxmox damit ich auch noch andere VMs und CTs laufen lassen kann. Die LAN Schnittstelle ist dann nachher tatsächlich auch an meinem Heimnetz angebunden, und eben dort soll der DHCP-Server die Adressen vergeben.

Ich hoffe das wird so deutlicher, ansonsten Zeichne ich die Topologie einmal auf.

In der OPNsense ist das Plugin auch aktiviert gewesen, auch in den anderen VMs. Aber natürlich immer nur einer zur gleichen Zeit.
Die Clients im Heimnetzwerk bekommen ihre IP immer vom DHCP-Server, das klappt auch immer problemlos bei DHCP-Servern außerhalb von Proxmox.
Die VMs und damit auch die Server (OPNsense, Nextcloud, etc.) bekommen eine feste IP.

 

[ph0x]

Ja, das ist schon klar.
Eine Skizze ist sicherlich nicht verkehrt, bitte auch noch die Fragen beantworten. Ich vermute, dass mit den Adressen was nicht passt ...

Wenn sowieso der gesamte Traffic durch die VM soll, brauchst du auch keine Bridge für WAN. Da kannst du der VM auch gleich das Interface geben. Du hängst ja üblicherweise auch keinen separaten Switch zwischen deinen Router und den DSL-Anschluss, oder?

 

[Scuruba]

Im Anhang mal mein Diagramm. Damit ist vielleicht auch klar was ich gemeint hab, dass die Bridge vmbr0 allen VMs und CTs zugeteilt wird.

Welche Adresse hat denn die Sense-VM?
Die OPNsense hat die IP 192.168.0.1, ich habe gerade oben in der Config auch gemerkt, dass hier das Gateway 192.168.0.10 ist. Das ist zur Zeit so beabsichtigt, da es mein alter Router ist der zur Zeit diese Adresse hat solange noch nicht alles funktioniert damit meine Freundin mich nicht erschlägt Während der Test auf die ich mich beziehe war das Gateway natürlich das der OPNsense.

Ist dort auch das DHCP-Plugin aktiviert?
Ja der dhcpd war aktiviert (grünes Feld mit Play-Symbol), solange ich den im Router deaktiviert hatte. Hatte den Dienst auch neu gestartet weil es nicht funktionierte und die OPNsense neu gestartet.

Und sind die anderen VMs so konfiguriert, dass sie einen DHCP suchen, ja?
Zum Teil ja, die Nextcloud nicht da sie eine feste IP hat, der HomeAssistant aber schon. Auch alle Teilnehmer im Heimnetz sind über DHCP konfiguriert.

Wenn sowieso der gesamte Traffic durch die VM soll, brauchst du auch keine Bridge für WAN. Da kannst du der VM auch gleich das Interface geben. Du hängst ja üblicherweise auch keinen separaten Switch zwischen deinen Router und den DSL-Anschluss, oder?

Ja das stimmt schon, hatte ich auch schon vor und hab es mal kurz versucht, dann hatte die OPNsense den Adapter aber gar nicht mehr gefunden. Ich muss mich damit noch mal beschäftigen, aber eins nach dem anderen Ich bin schon mal froh wenn der Rest erst einmal funktioniert

 

[ph0x]

Also grundsätzlich sieht das alles ziemlich ordentlich aus ...
Wie sieht es denn abseits von DHCP so aus? Kommt die Nextcloud über die Sense ins Internet? Kannst du die Sense vom HomeAssistant aus pingen? Haben andere CTs ähnliche Probleme mit dem Netz?
Der DHCP-Dienst läuft sicher auf dem LAN-Interface, ja? Da muss man nen Haken setzen, deshalb frag ich.
Falls das Netzwerk ansonsten funktioniert, würde ich auf ein Konfig-Problem in der Sense tippen. In dem Fall kannst du gern mal ein paar Screenshots der DHCP-Konfig machen.

 

[Scuruba]

Ich habe jetzt Pings gemacht von der Sense, UniFi Controller, Mac, AdGuardHome und HomeAssistant. Jeder konnte jeden erreichen.
Eine weile hatte ich auch schon die OPNsense als Firewall, und den Router nur als DHCP-Server laufen. Da hatte auch alles funktioniert bis auf das eigentliche Problem.

Angehangen habe ich jetzt folgendes:

1. DHCP-Config 2 Seiten, In den Untermenüs habe ich nichts eingestellt und es ist auch nichts eingetragen
2. Die Leases, ich habe deutlich mehr gerate im Netzwerk, wie man an Anhang im Protokoll auch sieht hat das MacBook auch angefragt, bekommt aber kein lease. Ein PC ist drin hat aber auch keine Adresse bekommen und der AdGuard ist drin hat aber die 192.168.0.2 über DHCP. Dies hat sich auch nicht geändert.
3. Das Protokoll des Servers vom Start. Danach geht es ewig weiter wenn das MacBook über die WLAN Schnittstelle anfragt und keine IP bekommt. (WLAN wurde auch aus und eingeschaltet und aktiv ein neues Lease angefragt)

Folgendes habe ich noch geschaut:

1. In der OPNsense in den Protokollen, ob dort die Ports 67-68 geblockt werden. Negativ...
2. mit "sudo dhclient -v" und "sudo dhcping -i", "sudo dhcping -r" sowie "sudo dhcping -i -v -s 192.168.0.1" geschaut ob ein DHCP-Server antwortet. Negativ -> mit eingeschaltetem DHCP-Client auf dem Router (192.168.0.10) geht "sudo dhclient -v" sowie "sudo dhcping -r -v -s 192.168.0.10", die anderen Befehle schlagen auch fehl
3. Mit dem Portscanner geschaut ob die Ports 67-68 per UDP offen sind auf 192.168.0.1 sowie 192.168.0.10 ja auf beiden ist da angeblich alles offen... aber leider auch jeder andere Port also muss man dem eigentlich keinen glauben schenken. Per TCP sind alle Ports geschlossen bis auf 443. Ich habe auch auch gelesen das man die Ports per UDP nicht verlässlich testen kann.
4. mit dem IPNetMonitorX (Netzwerktool) einen DHCP-Test gemacht. keine Antwort. Beim DHCP-Server des Routers alles i.O

Also wenn ich das richtig sehe "funktioniert" alles soweit, die DHCP-Anfragen kommen herein, werden aber nicht beantwortet.

 

[Scuruba]

Okay... sehr interessant. Ich habe jetzt mal die Bridge vmbr1 angeschlossen und hier nur die einen PiHole CT eingebunden, so dass niemand anderes darauf Zugriff hat.
Dann darauf den DHCP-Server aktiviert, und es funktioniert.... Vorher war er auf der LAN Bridge und hat nicht funktioniert.

Ich muss jetzt mal schauen was genau ich alles auf die Bridge konfigurieren kann bis es nicht mehr funktioniert. Weiß aber nicht ob ich das so schnell schaffe.

 

[ph0x]

Ändere mal bitte den Domänennamen auf localdomain oder irgendetwas anderes. local ist reserviert für mDNS-Anwendungen und gerade Apple nutzt das relativ extensiv. Nur um sicherzugehen, dass die Probleme keine Seiteneffekte dieser Einstellung sind.

 

[Scuruba]

Ändere mal bitte den Domänennamen auf localdomain oder irgendetwas anderes. local ist reserviert für mDNS-Anwendungen und gerade Apple nutzt das relativ extensiv. Nur um sicherzugehen, dass die Probleme keine Seiteneffekte dieser Einstellung sind.

Ich hatte jetzt mal etwas Zeit. Den DHCP-Server habe ich noch abgeändert.

Auch konnte ich die VMs auf die USB Bridge umziehen. Nun funktioniert alles, auch wenn ich das ganze schon einmal versucht hatte... Naja wirklich zufriedenstellen ist das jetzt nicht mit dem USB NIC aber naja es funktioniert erst einmal. Das war mir auf jeden Fall eine lehre, neue Hardware für Linux zu kaufen.

Ich danke dir auf jeden Fall für deine Hilfe

 

[karel1]

I have the same issue with the i225-LM NICs on the Intel NUC 11 Gen. (BNUC11TNHV50L00) with Proxmox VE 6.4-1. I have tested it with the latest 5.11-21 kernel and also tested with 5.12-11 kernel.
I used a VM with pfSense CE v2.5.1 and did a basic setup for testing. The WAN (i225-LM) works and also the LAN (i225-LM) is active. The thing that doesn't work on the LAN (i255-LM NIC) is the DHCP server.

I have tried all emulated options (VirtIO, Intel E1000, VMware vxmnet3) and also PCI passthrough of the LAN i225-LM (so using IGC driver of pfSense).
The laptop on the LAN side connected with a UTP cable to the LAN (i225-LM) NIC doesn't get an IP address from the DHCP server. When I switch the i225-LM with an USB-NIC in the pfSense VM the laptop does get an IP address from the DHCP server. I have attached a part of the PFSENSE/DHCP log file. The DHCPREQUEST and DHCPACK doesn';t happen on the i255-LM NIC.

PFSENSE DHCP server log output using the i225-LM NIC:
Jun 17 15:41:43 dhcpd 66392 Internet Systems Consortium DHCP Server 4.4.2
Jun 17 15:41:43 dhcpd 66392 Copyright 2004-2020 Internet Systems Consortium.
Jun 17 15:41:43 dhcpd 66392 All rights reserved.
Jun 17 15:41:43 dhcpd 66392 For info, please visit https://www.isc.org/software/dhcp/
Jun 17 15:41:43 dhcpd 66392 Config file: /etc/dhcpd.conf
Jun 17 15:41:43 dhcpd 66392 Database file: /var/db/dhcpd.leases
Jun 17 15:41:43 dhcpd 66392 PID file: /var/run/dhcpd.pid
Jun 17 15:41:43 dhcpd 66392 Internet Systems Consortium DHCP Server 4.4.2
Jun 17 15:41:43 dhcpd 66392 Copyright 2004-2020 Internet Systems Consortium.
Jun 17 15:41:43 dhcpd 66392 All rights reserved.
Jun 17 15:41:43 dhcpd 66392 For info, please visit https://www.isc.org/software/dhcp/
Jun 17 15:41:43 dhcpd 66392 Wrote 0 class decls to leases file.
Jun 17 15:41:43 dhcpd 66392 Wrote 0 leases to leases file.
Jun 17 15:41:43 dhcpd 66392 Listening on BPF/vtnet0/b2:37:09:f7:e8:f6/192.168.2.0/24
Jun 17 15:41:43 dhcpd 66392 Sending on BPF/vtnet0/b2:37:09:f7:e8:f6/192.168.2.0/24
Jun 17 15:41:43 dhcpd 66392 Sending on Socket/fallback/fallback-net
Jun 17 15:41:43 dhcpd 66392 Server starting service.
Jun 17 15:41:47 dhcpd 66392 DHCPDISCOVER from 74:83:c2:fa:db:65 via vtnet0
Jun 17 15:41:48 dhcpd 66392 DHCPOFFER on 192.168.2.200 to 74:83:c2:fa:db:65 via vtnet0
Jun 17 15:42:11 dhcpd 66392 DHCPDISCOVER from b8:88:e3:9b:6f:e9 via vtnet0
Jun 17 15:42:12 dhcpd 66392 DHCPOFFER on 192.168.2.201 to b8:88:e3:9b:6f:e9 (laptop-Lenovo-IdeaPad-Y500) via vtnet0
Jun 17 15:42:13 dhcpd 66392 DHCPDISCOVER from b8:88:e3:9b:6f:e9 (laptop-Lenovo-IdeaPad-Y500) via vtnet0
Jun 17 15:42:13 dhcpd 66392 DHCPOFFER on 192.168.2.201 to b8:88:e3:9b:6f:e9 (laptop-Lenovo-IdeaPad-Y500) via vtnet0
Jun 17 15:42:18 dhcpd 66392 DHCPDISCOVER from b8:88:e3:9b:6f:e9 (laptop-Lenovo-IdeaPad-Y500) via vtnet0
Jun 17 15:42:18 dhcpd 66392 DHCPOFFER on 192.168.2.201 to b8:88:e3:9b:6f:e9 (laptop-Lenovo-IdeaPad-Y500) via vtnet0
Jun 17 15:42:27 dhcpd 66392 DHCPDISCOVER from b8:88:e3:9b:6f:e9 (laptop-Lenovo-IdeaPad-Y500) via vtnet0
Jun 17 15:42:27 dhcpd 66392 DHCPOFFER on 192.168.2.201 to b8:88:e3:9b:6f:e9 (laptop-Lenovo-IdeaPad-Y500) via vtnet0
Jun 17 15:42:43 dhcpd 66392 DHCPDISCOVER from b8:88:e3:9b:6f:e9 (laptop-Lenovo-IdeaPad-Y500) via vtnet0
Jun 17 15:42:43 dhcpd 66392 DHCPOFFER on 192.168.2.201 to b8:88:e3:9b:6f:e9 (laptop-Lenovo-IdeaPad-Y500) via vtnet0


PFSENSE DHCP server log output using the USB-NIC:
Jun 17 15:51:23 dhcpd 67278 Internet Systems Consortium DHCP Server 4.4.2
Jun 17 15:51:23 dhcpd 67278 Copyright 2004-2020 Internet Systems Consortium.
Jun 17 15:51:23 dhcpd 67278 All rights reserved.
Jun 17 15:51:23 dhcpd 67278 For info, please visit https://www.isc.org/software/dhcp/
Jun 17 15:51:23 dhcpd 67278 Config file: /etc/dhcpd.conf
Jun 17 15:51:23 dhcpd 67278 Database file: /var/db/dhcpd.leases
Jun 17 15:51:23 dhcpd 67278 PID file: /var/run/dhcpd.pid
Jun 17 15:51:23 dhcpd 67278 Internet Systems Consortium DHCP Server 4.4.2
Jun 17 15:51:23 dhcpd 67278 Copyright 2004-2020 Internet Systems Consortium.
Jun 17 15:51:23 dhcpd 67278 All rights reserved.
Jun 17 15:51:23 dhcpd 67278 For info, please visit https://www.isc.org/software/dhcp/
Jun 17 15:51:23 dhcpd 67278 Wrote 0 class decls to leases file.
Jun 17 15:51:23 dhcpd 67278 Wrote 0 leases to leases file.
Jun 17 15:51:23 dhcpd 67278 Listening on BPF/vtnet0/7a:e0:7e:8b:26:10/192.168.2.0/24
Jun 17 15:51:23 dhcpd 67278 Sending on BPF/vtnet0/7a:e0:7e:8b:26:10/192.168.2.0/24
Jun 17 15:51:23 dhcpd 67278 Sending on Socket/fallback/fallback-net
Jun 17 15:51:23 dhcpd 67278 Server starting service.
Jun 17 15:55:45 dhcpd 67278 DHCPDISCOVER from b8:88:e3:9b:6f:e9 via vtnet0
Jun 17 15:55:46 dhcpd 67278 DHCPOFFER on 192.168.2.200 to b8:88:e3:9b:6f:e9 (laptop-Lenovo-IdeaPad-Y500) via vtnet0
Jun 17 15:55:46 dhcpd 67278 DHCPREQUEST for 192.168.2.200 (192.168.2.1) from b8:88:e3:9b:6f:e9 (laptop-Lenovo-IdeaPad-Y500) via vtnet0
Jun 17 15:55:46 dhcpd 67278 DHCPACK on 192.168.2.200 to b8:88:e3:9b:6f:e9 (laptop-Lenovo-IdeaPad-Y500) via vtnet0
Jun 17 15:55:47 dhcpd 67278 DHCPDISCOVER from 74:83:c2:fa:db:65 via vtnet0
Jun 17 15:55:48 dhcpd 67278 DHCPOFFER on 192.168.2.201 to 74:83:c2:fa:db:65 via vtnet0
Jun 17 15:55:48 dhcpd 67278 DHCPREQUEST for 192.168.2.201 (192.168.2.1) from 74:83:c2:fa:db:65 via vtnet0
Jun 17 15:55:48 dhcpd 67278 DHCPACK on 192.168.2.201 to 74:83:c2:fa:db:65 (USW_MINI) via vtnet0
Jun 17 15:56:17 dhcpd 67278 reuse_lease: lease age 31 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.2.200
Jun 17 15:56:17 dhcpd 67278 DHCPDISCOVER from b8:88:e3:9b:6f:e9 (laptop-Lenovo-IdeaPad-Y500) via vtnet0


I have also tested this issue on ESXI 7 update 2. The same behaviour as on proxmox occurs. So no working DHCP server on the i225-LM NIC.

Using an i225-LM NIC as a DHCP server in Proxmox VE doesn't seem to work at the moment. Or did anyone fixed the issue to use a DHCP server on proxmox?

But more important. How can we troubleshoot the issue so that we know the root cause?
1. Is it a driver issue? Intel/IGC?
2. Debian OS issue?
3. Proxmox?

edit: After some more reading and switching from Linux bridge to OVS bridge. The OVS does seem to give out IP adresses. So it seems that the Linux bridge is the issue here. Maybe the linux bridge needs to be fixed for the i225-lm NICS?

Conclusion. When using Linux Bridge with i225-LM NIC the DHCP server doesn't work correctly. When switching from Linux Bridge to OVS bridge the DHCP server does work correctly!

 

[anaxma]

Anyone else still with the issue described in this thread (in my case on an Intel NUC 12 Pro, also with I225-LM) ? I tried switching the bridge to OVS but it didn't help in my case - my pihole LXC container receives the DISCOVER package, sends an OFFER package (that I can see with tcpdump on PVE), but that package gets dropped somewhere as it doesn't appear on tcpdump anywhere on the same network.

 

[rfox]

Looks like I may have a similar problem - using R86s with 3xi225-LM and 2x10GB Mellanox - running latest Proxmox and OPNSense as VM - OPNSense serving up IPs through DHCP - having issues between VLANs and DHCP broadcast :-( Been racking my brain trying to figure out why certain devices can get a DHCP address during Discover . . . So maybe it's a driver issue ?!?

I will try the OVS Bridge instead as well . . .