[SOLVED] DHCP Server (VM) liefert keine IP Adressen über vmbr0 an die physikalische Schnittstelle nach außen, intern funktioniert dieser (MS 01, INTEL I226 LM)

loeserman

New Member
Jun 19, 2025
6
2
3
Hallo zusammen,
ich habe ein merkwürdiges Problem. Ich nutze in Proxmox 8.4.11 eine VM mit pfSense. Die pfSense dient als Firewall zwischen mehreren Netzen und auch dem WAN und zugleich auch als DHCP Server für 3 der 4 Netze (LAN, INT, GST).

Das angehangene Bild verdeutlicht den Aufbau20250825_103317_20250825_ProxmoxNetzwerkÜbersicht.pptx - PowerPoint-Referentenansicht.png

Mein Problem ist nun, dass die physikalischen PCs am LAN keine DHCP IP Adresse zugewiesen bekommen. Es scheint für sie, als sei kein DHCP Server vorhanden. Schließe ich den gleichen PC an INT oder GST an erhält dieser sofort eine IP Adresse.

Der DHCP Server scheint aber zu funktionieren, da die Test VM immer sofort eine IP aus dem jeweiligen Band zugewiesen bekommt. Egal mit welchem vmbr (0,1,2) ich sie verbinde.

Es hat den Anschein, dass die DHCP Telegramme es nicht über den enp90s schaffen.

Weise ich den physikalischen PCs am LAN eine feste IP zu, dann läuft alles einwandfrei. Es geht lediglich um DHCP. Nachgelagerte Switche kann ich auch ausschließen. Ich habe den Test auch mit einem PC gemacht, der direkt an den LAN Port (enp90s0) eingesteckt war. Dieser hat ebenfalls keine DHCP IP Adresse zugewiesen bekommen.

Auch habe ich in meiner Verzweifelung versucht das ageing auf 0 zu setzen. Hat jedoch keinen Erfolg gebracht.

Anbei meine /etc/network/interfaces.conf
Code:
auto lo
iface lo inet loopback

auto enp90s0
iface enp90s0 inet manual
        post-up /sbin/ethtool -s enp90s0 wol g
#58:47:CA:7D:CA:3F - 2.5GBit/s von hinten on board, links

iface enp2s0f0np0 inet manual
#58:47:CA:7D:CA:3C - 10GBit/s von hinten SFP Modul, XXX

iface enp2s0f1np1 inet manual
#58:47:CA:7D:CA:3D - 10GBit/s von hinten SFP Modul, XXX

auto enp87s0
iface enp87s0 inet manual
#58:47:CA:7D:CA:3E - 2.5GBit/s von hinten on board, rechts

iface wlp90s0 inet manual

auto enxc8a362d067fe
iface enxc8a362d067fe inet manual
#C8:A3:62:D0:67:FE - 1GBit/s USB Adapter (WAN)

auto enxc8a362d06297
iface enxc8a362d06297 inet manual
#C8:A3:62:D0:62:97 - 1Gbit/s USB Adapter (GST)

iface wlp91s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.xxx.xxx/24
        gateway 192.168.xxx.xxx
        bridge-ports enp90s0
        bridge-stp off
        bridge-fd 0
        bridge-ageing 0
#LAN (incl administration pve0)

auto vmbr1
iface vmbr1 inet manual
        bridge-ports enp87s0
        bridge-stp off
        bridge-fd 0
#INT

auto vmbr2
iface vmbr2 inet manual
        bridge-ports enxc8a362d06297
        bridge-stp off
        bridge-fd 0
#GST

auto vmbr3
iface vmbr3 inet manual
        bridge-ports enxc8a362d067fe
        bridge-stp off
        bridge-fd 0
#WAN

ip addr liefert das folgende Ergebnis
Code:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp87s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr1 state UP group default qlen 1000
    link/ether 58:47:ca:7d:ca:3e brd ff:ff:ff:ff:ff:ff
3: enp90s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
    link/ether 58:47:ca:7d:ca:3f brd ff:ff:ff:ff:ff:ff
4: enp2s0f0np0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 58:47:ca:7d:ca:3c brd ff:ff:ff:ff:ff:ff
5: enp2s0f1np1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 58:47:ca:7d:ca:3d brd ff:ff:ff:ff:ff:ff
6: enxc8a362d067fe: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr3 state UP group default qlen 1000
    link/ether c8:a3:62:d0:67:fe brd ff:ff:ff:ff:ff:ff
7: enxc8a362d06297: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr2 state UP group default qlen 1000
    link/ether c8:a3:62:d0:62:97 brd ff:ff:ff:ff:ff:ff
8: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 58:47:ca:7d:ca:3f brd ff:ff:ff:ff:ff:ff
    inet 192.168.123.xxx/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::5a47:caff:fe7d:ca3f/64 scope link
       valid_lft forever preferred_lft forever
9: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 58:47:ca:7d:ca:3e brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5a47:caff:fe7d:ca3e/64 scope link
       valid_lft forever preferred_lft forever
10: vmbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether c8:a3:62:d0:62:97 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::caa3:62ff:fed0:6297/64 scope link
       valid_lft forever preferred_lft forever
11: vmbr3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether c8:a3:62:d0:67:fe brd ff:ff:ff:ff:ff:ff
    inet6 fe80::caa3:62ff:fed0:67fe/64 scope link
       valid_lft forever preferred_lft forever
12: wlp91s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 3c:c5:dd:49:b1:3d brd ff:ff:ff:ff:ff:ff
21: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
    link/ether 7a:b4:18:21:08:57 brd ff:ff:ff:ff:ff:ff
22: tap100i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr1 state UNKNOWN group default qlen 1000
    link/ether 06:fb:da:8c:57:01 brd ff:ff:ff:ff:ff:ff
23: tap100i2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr2 state UNKNOWN group default qlen 1000
    link/ether e6:d7:1a:03:3e:bb brd ff:ff:ff:ff:ff:ff
24: tap100i3: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr3 state UNKNOWN group default qlen 1000
    link/ether c2:fc:46:d1:8b:9d brd ff:ff:ff:ff:ff:ff

Auch habe ich mir mal die fdb ausgeben lassen und etwas sortiert. So recht sehe ich hier aber auch kein Probem
Code:
bridge fdb show

<< LAN >>
58:47:ca:7d:ca:3f dev enp90s0 vlan 1 master vmbr0 permanent
58:47:ca:7d:ca:3f dev enp90s0 master vmbr0 permanent
33:33:00:00:00:01 dev enp90s0 self permanent
01:00:5e:00:00:01 dev enp90s0 self permanent
33:33:00:00:00:01 dev vmbr0 self permanent
33:33:00:00:00:02 dev vmbr0 self permanent
01:00:5e:00:00:6a dev vmbr0 self permanent
33:33:00:00:00:6a dev vmbr0 self permanent
01:00:5e:00:00:01 dev vmbr0 self permanent
33:33:ff:7d:ca:3f dev vmbr0 self permanent
33:33:ff:00:00:00 dev vmbr0 self permanent
7a:b4:18:21:08:57 dev tap100i0 vlan 1 master vmbr0 permanent
7a:b4:18:21:08:57 dev tap100i0 master vmbr0 permanent
33:33:00:00:00:01 dev tap100i0 self permanent
01:00:5e:00:00:01 dev tap100i0 self permanent

<< INT >>
58:47:ca:7d:ca:3e dev enp87s0 vlan 1 master vmbr1 permanent
58:47:ca:7d:ca:3e dev enp87s0 master vmbr1 permanent
33:33:00:00:00:01 dev enp87s0 self permanent
01:00:5e:00:00:01 dev enp87s0 self permanent
08:f9:e0:ea:bf:83 dev enp87s0 master vmbr1
fc:84:a7:4f:38:b4 dev enp87s0 master vmbr1
10:32:2c:68:b7:30 dev enp87s0 master vmbr1
b0:65:3a:7e:e5:d4 dev enp87s0 master vmbr1
fc:84:a7:4f:38:ac dev enp87s0 master vmbr1
78:f5:05:7f:9d:d4 dev enp87s0 master vmbr1
d8:eb:97:cd:1d:e0 dev enp87s0 master vmbr1
cc:8d:a2:20:ee:fc dev enp87s0 master vmbr1
cc:8d:a2:20:ef:54 dev enp87s0 master vmbr1
cc:8d:a2:1f:f4:a0 dev enp87s0 master vmbr1
cc:8d:a2:1f:f1:3c dev enp87s0 master vmbr1
cc:8d:a2:20:eb:00 dev enp87s0 master vmbr1
80:1f:02:b6:03:0b dev enp87s0 master vmbr1
40:d6:3c:79:dc:76 dev enp87s0 master vmbr1
00:03:ac:4d:9e:46 dev enp87s0 master vmbr1
ec:71:db:46:b7:41 dev enp87s0 master vmbr1
40:a8:f0:71:9c:82 dev enp87s0 master vmbr1
00:03:ac:4d:78:c2 dev enp87s0 master vmbr1
33:33:00:00:00:01 dev vmbr1 self permanent
01:00:5e:00:00:6a dev vmbr1 self permanent
33:33:00:00:00:6a dev vmbr1 self permanent
01:00:5e:00:00:01 dev vmbr1 self permanent
33:33:ff:7d:ca:3e dev vmbr1 self permanent
bc:24:11:28:6c:65 dev tap100i1 master vmbr1
06:fb:da:8c:57:01 dev tap100i1 vlan 1 master vmbr1 permanent
06:fb:da:8c:57:01 dev tap100i1 master vmbr1 permanent
33:33:00:00:00:01 dev tap100i1 self permanent
01:00:5e:00:00:01 dev tap100i1 self permanent

<< GST >>
c8:a3:62:d0:62:97 dev enxc8a362d06297 vlan 1 master vmbr2 permanent
c8:a3:62:d0:62:97 dev enxc8a362d06297 master vmbr2 permanent
33:33:00:00:00:01 dev enxc8a362d06297 self permanent
01:00:5e:00:00:01 dev enxc8a362d06297 self permanent
1a:ca:9d:8f:55:d2 dev enxc8a362d06297 master vmbr2
50:23:6d:51:5d:13 dev enxc8a362d06297 master vmbr2
70:ee:50:6f:99:46 dev enxc8a362d06297 master vmbr2
64:90:c1:18:ba:f1 dev enxc8a362d06297 master vmbr2
40:a8:f0:71:9c:82 dev enxc8a362d06297 master vmbr2
33:33:00:00:00:01 dev vmbr2 self permanent
01:00:5e:00:00:6a dev vmbr2 self permanent
33:33:00:00:00:6a dev vmbr2 self permanent
01:00:5e:00:00:01 dev vmbr2 self permanent
33:33:ff:d0:62:97 dev vmbr2 self permanent
bc:24:11:ac:14:33 dev tap100i2 master vmbr2
e6:d7:1a:03:3e:bb dev tap100i2 vlan 1 master vmbr2 permanent
e6:d7:1a:03:3e:bb dev tap100i2 master vmbr2 permanent
33:33:00:00:00:01 dev tap100i2 self permanent
01:00:5e:00:00:01 dev tap100i2 self permanent

<< WAN >>
c8:a3:62:d0:67:fe dev enxc8a362d067fe vlan 1 master vmbr3 permanent
c8:a3:62:d0:67:fe dev enxc8a362d067fe master vmbr3 permanent
33:33:00:00:00:01 dev enxc8a362d067fe self permanent
01:00:5e:00:00:01 dev enxc8a362d067fe self permanent
c0:25:06:29:bb:2e dev enxc8a362d067fe master vmbr3
40:a8:f0:71:9c:82 dev enxc8a362d067fe master vmbr3
33:33:00:00:00:01 dev vmbr3 self permanent
01:00:5e:00:00:6a dev vmbr3 self permanent
33:33:00:00:00:6a dev vmbr3 self permanent
01:00:5e:00:00:01 dev vmbr3 self permanent
33:33:ff:d0:67:fe dev vmbr3 self permanent
bc:24:11:64:72:98 dev tap100i3 master vmbr3
c2:fc:46:d1:8b:9d dev tap100i3 vlan 1 master vmbr3 permanent
c2:fc:46:d1:8b:9d dev tap100i3 master vmbr3 permanent
33:33:00:00:00:01 dev tap100i3 self permanent
01:00:5e:00:00:01 dev tap100i3 self permanent

<< NICHT VERWENDETE SCHNITTSTELLEN >>
33:33:00:00:00:01 dev enp2s0f0np0 self permanent
33:33:00:00:00:01 dev enp2s0f1np1 self permanent
33:33:00:00:00:01 dev wlp91s0 self permanent

Nun bin ich ratlos. Zumal das schon mal funktioniert hat, aber ich weiss nicht mehr genau bis wann. Was könnte ich geändert haben? Wo könnte ich suchen, um das wieder hin zu bekommen?

Ich habe irgendwann einen zweiten Node (pve1) aufgebaut und somit ein 2node Cluster (ich weiss man bräuchte 3). Bin mir jedoch recht sicher, dass es danach noch ging.

Vor kurzen habe ich über die Update Funktion auch beide notes mal geupdated. Hoffentlich lag es nicht daran.

Migriere ich die pfSense VM zu dem anderen Proxmox Server (pve1), dann läuft alles und ich erhalte auch extern die gewünschten DHCP IP Adressen auf dem LAN zugewiesen. Hole ich sie wieder zurück zum pve0 geht es nicht mehr (wie oben beschrieben). Ansonsten haben sie eine nahezu gleiche Config (ist nicht die gleiche Hardware). Der node2 ist auch nicht immer an.

Ich hoffe ihr habt Ideen wo ich hinsehen muss/kann. Ich bin mit meinem Latein etwas am Ende. Möchte es aber gern wieder hinbekommen, um eine Neuinstallation mit ungewissem Ausgang vermeiden.

Vielen Dank an das Forum.

Gruß
Christoph
 
Last edited:
Habe noch etwas weitergeforscht. Seltsamerweise bleibt die DHCP Offer im physikalischen Interface hängen.

Folgendes habe ich nun mal probiert:
+ pfSense läuft weiter wie gehabt
+ ich stecke einen PC direkt auf die LAN Schnittstelle vom Proxmox (enp90s0)
+ dabei mache ich Wireshark Aufzeichnungen von
+ A: Der Netzwerkschnittstelle des PCs
+ B: Der physikalischen Netzwerkschnittstelle vom Proxmox (enp90s0)
+ C: Der Linux Brücke (vmbr0) für das LAN
+ D: Dem Netzwerkadapter der pfSense VM (tap100i0)

20250825_134202_20250825_ProxmoxNetzwerkÜbersicht.pptx - PowerPoint-Referentenansicht.png


Das Ergebnis zeigt:

A: PC
Hier wird ein Discover abgesendet. Er erhält aber nie ein Offer Paket
20250825_132435_dumpB_SURFACE.pcapng.png


B: Physikalische Schnittstelle des Proxmox Servers
Hier wird das Discover empfangen und es kommt sogar ein Offer zurück.
Wo geht das nun verloren??
20250825_132450_dumpB_enp90s0.pcap.jpg


C: Linux Brücke für das LAN
Hier wird das Discover empfangen und es kommt sogar ein Offer zurück.
20250825_132534_dumpB_vmbr0.pcap.jpg


D: Netzwerkadapter der pfSense für das LAN
Hier wird das Discover empfangen und es kommt sogar ein Offer zurück.
20250825_132555_dumpB_tap100i0.pcap.jpg


Anderes Interface INT funktioniert (Aufnahmepunkt A aber eben andere Schnittstelle vom Proxmox Server)
Auf einer anderen Schnittstelle (ebenfalls onboard, gleicher Typ) funktioniert das und ich erhalte den vollständigen DHCP Verlauf. Das sieht dann auf dem PC folgendermaßen aus, wie man es auch erwarten würde.
20250825_134728_surface_direkt_INT.pcapng.jpg


Die Große Frage ist nun für mich, wie kann es sein, dass ich das DHCP Offer Telegram im TCPDump von der Schnittstelle enp0s0 noch sehe, aber außen auf dem Kabel ist es dann nicht mehr? Habt ihr da Ideen, das ging auf jeden Fall schon mal.

Kann ich sehen, welche Updates ich wann eingespielt habe. Sieht man dort ggf. ob neue Netzwerktreiber dabei waren?

Danke euch im Voraus für's Helfen. Ich hoffe ich/wir finden das noch.

Gruß
Christoph
 
Last edited:
Hallo Christoph,

Kann ich sehen, welche Updates ich wann eingespielt habe. Sieht man dort ggf. ob neue Netzwerktreiber dabei waren?
Das findet man in /var/log/dpkg.log*

Das Paket, welches den Treiber enthält, findest Du mit ein paar Schritten, hab das mal hier für mein System gemacht, musst du natürlich mit ein paar Anpassungen machen:

1. Herausfinden welcher Treiber es überhaupt ist:

Code:
lspci -knn | grep -A 3 -i Ethernet
Code:
03:00.0 Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe [14e4:165f]
    DeviceName: NIC Port 1
    Subsystem: Hewlett-Packard Company NC332i Adapter [103c:2133]
    Kernel driver in use: tg3

Es ist also der Kernel driver "tg3".

2. Das passende Kernel-Modul suchen:

Code:
find /lib/modules/6.8.12-11-pve|grep tg3

Code:
/lib/modules/6.8.12-11-pve/kernel/drivers/net/ethernet/broadcom/tg3.ko

3. Das Debian-Paket zu dieser Datei herausfinden:

Code:
dpkg -S /lib/modules/6.8.12-11-pve/kernel/drivers/net/ethernet/broadcom/tg3.ko

Code:
proxmox-kernel-6.8.12-11-pve-signed: /lib/modules/6.8.12-11-pve/kernel/drivers/net/ethernet/broadcom/tg3.ko

4. Da kannst Du jetzt nachsehen, ob/wann das geupdated wurde:

Code:
zgrep proxmox-kernel-6.8.12-11-pve-signed /var/log/dpkg.log*

Code:
/var/log/dpkg.log.1:2025-05-26 22:13:06 install proxmox-kernel-6.8.12-11-pve-signed:amd64 <none> 6.8.12-11
/var/log/dpkg.log.1:2025-05-26 22:13:06 status half-installed proxmox-kernel-6.8.12-11-pve-signed:amd64 6.8.12-11
/var/log/dpkg.log.1:2025-05-26 22:13:13 status unpacked proxmox-kernel-6.8.12-11-pve-signed:amd64 6.8.12-11
/var/log/dpkg.log.1:2025-05-26 22:13:25 configure proxmox-kernel-6.8.12-11-pve-signed:amd64 6.8.12-11 <none>
/var/log/dpkg.log.1:2025-05-26 22:13:25 status unpacked proxmox-kernel-6.8.12-11-pve-signed:amd64 6.8.12-11
/var/log/dpkg.log.1:2025-05-26 22:13:25 status half-configured proxmox-kernel-6.8.12-11-pve-signed:amd64 6.8.12-11
/var/log/dpkg.log.1:2025-05-26 22:13:58 status installed proxmox-kernel-6.8.12-11-pve-signed:amd64 6.8.12-11

Bei mir also am 26. Mai ;-)

Bei Deinem DHCP Problem kann ich dir leider auch nicht helfen, aber da gibt es hoffentlich Leute, die sich besser auskennen...

VG
Felix
 
Last edited:
Danke Felix!

So nun habe ich noch viel geforscht und bin zu einem Ergebnis gekommen.
"Bug in der Netzwerkkarte von INTEL I226 LM"

Hintergrund:

Mein Proxmox Server ist ein MS 01 (Miniforum) und dieser hat zwei feste und zwei SFP+ Schnittstellen. Für meine vier Schnittstelle nutze ich die beiden festen und zwei externe USB/Lan Koppler.
Bei den beiden festen Netzwerk Schnittstellen handelt es sich um INTEL I226 V (enp87s0) und I226 LM (enp90s0). Die LM Schnittstelle verfügt über das AMT, weshalb ich diese für meine Hauptschnittstellen (LAN) ausgewählt habe. So war ich in der Lage den Proxmox Server normal im Netzwerk zu erreichen aber auch über eine 2. IP Adresse über den Mesh Commander (AMT) in die BIOS Einstellungen zu gucken. Das lief auch alles wie gewünscht. Eigentlich prima.

Nun kam folgende Änderung hinzu:
Ich habe einen 3. 1TB NVME M.2 Speicherriegel hinzugesteckt. Ich vermute, dass das der Auslöser war. Als die noch nicht drin war, lief ja noch alles. Eventuell teilt sich der M.2 Slot eine PCI-Lane mit genau der I226 LM Netzwerkkarte (Vermutung).

Dies hat dann vermutlich zur Folge, dass die INTEL I226 LM (für mein LAN) Netzwerk Probleme macht. Aufmerksam hat mich hierauf folgender Satz in dem Problemreport bei Intel gemacht: "I found that removing the M.2 on the chipset (not the one connected to CPU) activated the full functions of the I226LM on my Asus W680 board"
siehe: https://community.intel.com/t5/Ethernet-Products/I226-LM-won-t-send-DHCPOFFER/td-p/1620544

Das ist zwar ein anderes Board, aber dennoch sehr verdächtig, dass genau M.2 genannt wird, welches die Funktionalität einschränkt. Anscheinend wird das DHCP Offer Telegram als AMT Telegram verstanden und direkt von der INTEL Netzwerkschnittstelle verschluckt. Bisher hat diesen Bug zwar INTEL erkannt jedoch nach meinem Wissen noch nicht behoben. Da ich den neuen NVME M.2 Speicher jedoch schon in Benutzung habe und der Server wieder installiert ist, habe ich sie nicht nochmal ausgebaut um das zu verifizieren.

Manchmal wird auch empfohlen AMT auszuschalten oder ggf. auch nur ASPM im BIOS zu deaktivieren. Dieses möchte ich jedoch auch nicht. Ich möchte die AMT Funktionalität ja nutzen.

Was auch gehen soll ist mit VLANs zu arbeiten, dann gehen die DHCP Offers durch. Ich habe zwar VLANs, wollte die Konfiguration aber nicht zu sehr verkomplizieren. Ich möchte das auch in ein paar Jahren noch verstehen, was da eingestellt ist. Aber wenn man über die I226 LM Schnittstelle per VLAN arbeitet, dann geht das wohl, da das AMT ja auch nur auf VLAN 1 (also Standard/Untagged) arbeitet.

Lösung für mich
Ich habe mich dazu entschieden, den I226 LM Port für das WAN zu nutzen (hier habe ich kein DHCP von innen über die pfSense, sondern von außen über die Fritzbox. DHCP interessiert mich hierbei bei dem Proxmox Server und den innen laufenden VMs nicht. Sind alles feste IPs.

Somit habe ich einfach über die /etc/network/interfaces folgende Anpassung vorgenommen
LAN: vmbr0 --> enp87s0 vorher: enp90s0
INT: vmbr1 --> enxc8a362d067fe vorher: enp87s0
GST: vmbr2 --> enxc8a362d06297
WAN: vmbr3 --> enp90s0 vorher: enxc8a362d067fe (da hier kein DHCP benötigt wird)

Das AMT Interface habe ich dann auch umgestellt auf eine IP Adresse aus dem WAN Band, so dass ich es hoffentlich ebenfalls über die Firewall erreichen kann.

Dennoch Danke an alle, die den Post gelesen und vielleicht sich schon Gedanken gemacht haben, wie wir der Sache auf den Grund gehen könnten.

Weitere Links:
https://www.reddit.com/r/PFSENSE/comments/1hyxjcu/minisforum_ms01_nic_issue_ce/
https://www.reddit.com/r/opnsense/comments/1bap0k5/issue_with_intermittent_upload_speeds_with_ms01/
https://bbs.archlinux.org/viewtopic.php?id=298063
https://forum.proxmox.com/threads/dhcp-server-not-working-with-minisforum-ms-01.166824/
https://forum.netgate.com/topic/188141/cannot-get-dhcp-functioning-on-2nd-interface
https://spaceterran.com/posts/step-by-step-guide-enabling-intel-vpro-on-your-minisforum-ms-01-bios/
 
  • Like
Reactions: luckyspiff and UdoB
Noch ein kleiner Nachtrag für Interessierte

Ich habe ja die INTEL I226 LM Karte mit der AMT Funktion belassen, diese aber in das WAN umgelenkt (natürlich immer noch hinter der Fritzbox, damit nicht unsicher). Somit habe ich der AMT Funktion auch eine IP Adresse aus dem WAN Band gegeben. Dabei hatte ich dann im Hinterkopf, dass ich dann über die pfSense diese auch aus dem LAN erreichen kann. Theoretisch geht das auch, wenn hierbei nicht die Schnittstelle selbst im Spiel wäre.

20250827_102032_20250825_ProxmoxNetzwerkÜbersicht.pptx - PowerPoint-Referentenansicht.png

A) PC sendet Telegramma an die IP Adresse des AMT Interfaces im WAN Netz
B) Diese kommen auch am LAN Interface der pfSense an
C) Die pfSense routet diese auch wieder an das WAN Netz weiter
D) Am physikalischen WAN Interface kommen diese nicht mehr heraus (geschluckt)

Das die Telegramme nicht mehr physikalisch rausgehen, hätte ich noch so halb verstanden auch, wenn es zwei unterschiedliche IP Adressen sind aus dem WAN Band (WAN IP Adresse der pfSense UNGLEICH der WAN IP Adresse des AMT Interfaces). Aber AMT schluckt es einfach und verwirft es. Sie müssen anscheinend von Außen kommen.

Wenn man das erreichen möchte, dann muss man die INTEL I226 LM Schnittstelle (enp90s0) nur für AMT vorsehen und in meinem Fall für das WAN noch eine anderen Adapter nehmen. Dann kann man die Schnittstelle auch gleich wieder ins LAN hängen. Aber das wäre Verschwendung aus meiner Sicht.

Was immer noch geht. Einen PC ins WAN hängen (siehe temporäre Verbindung) und dann direkt per Mesh Commander auf die IP zugreifen. Das funktioniert auch wie erwartet. Da ich mit VLANs arbeite, kann ich das prinzipiell jederzeit bewerkstelligen und muss dafür nicht in den Keller :-)

Naja das soll es dann aber auch gewesen sein. Für mich habe ich so einen Weg gefunden, der für mich ausreichend ist.

Vielleicht hilft es ja jemanden, der auch vor einem solchen oder ähnlichem Problem steht.
 
Last edited: