28.01.2025, aktualisiert um 12:45:14 Uhr

1428

OPNsense - 2 verschiedene einzelne Clients bekommen keine DHCP-Adresse im VLAN

Hallo miteinander,
ich habe eine OPNsense (macht DHCP) mit verschiedenen VLANs am laufen.
Dahinter Switched ein TP-Link TL-SG3428MP.
Grundlegend funktioniert das DHCP in den verschiedenen VLAN einwandfrei, allerdings habe ich 2 Endgeräte die einfach keine IP-Adresse per DHCP erhalten.

Das eine ist ein OKI MB472 Drucker das andere ist das Webinterface der Heizung (Waterkotte).
Die beiden Endgeräte habe ich auf DHCP umgestellt und den jeweiligen Port am Switch auch auf das entsprechende VLAN gestellt. Dies anschließend durch den Anschluss eines PC gecheckt, dieser erhält dann auch sauber eine DHCP-IP-Adresse im gewünschten VLAN.
Wenn ich aber anschließend den Drucker oder die Heizung an den (zuvor erfolgreich getesteten) Port anschließe erhalte ich bei beiden Geräten keine IP per DHCP.

Meine Frage ist nun:
Wo kann ich denn jetzt zu meinem Problem Hinweise/Logs finden?
In der OPNsense konnte ich bisher dazu nix finden.

Vielen Dank für jegliche Hinweise oder Ideen!
MfG
Seggel

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 670996

Url: https://administrator.de/forum/opnsense-2-verschiedene-einzelne-clients-bekommen-keine-dhcp-adresse-im-vlan-670996.html

Ausgedruckt am: 12.03.2025 um 10:03 Uhr

31 Kommentare

Neuester Kommentar

Moin,
Drucker und Heizung riecht für mich so nach Fast-Ethernet-Geräten (100MBit/s).
Bekommen die Geräte denn am Switch überhaupt einen Link? Was passiert, wenn Du die beiden Switchports mal konkret auf 100MBit/s FullDuplex einstellst?

Ansonsten einen der betroffenen Switchports spiegeln und mit dem Kabelhai mal tracken, was dort DHCP-Discover, -Offer, -Request mässig so stattfindet.

Grüße,
Torsten

Moin,

Unsere MFPs brauchen einen Neustart, wenn sich das VLAN/ die IP ändern soll.

Schließe also mal (zuerst) den Drucker am Zielport an, schalte den Drucker aus und dann wieder an.

Das gleiche dann auch an der Heizung mal testen.

Bekommen die Geräte denn am Switch überhaupt einen Link? Was passiert, wenn Du die beiden Switchports mal konkret auf 100MBit/s FullDuplex einstellst?

Hab eben mal die Specs des Druckers dazu angeschaut, lt. Datenblatt kann er "1000BASE-T/100BASE-TX/10BASE-T"
Dennoch werde ich das aber bei nächster Gelegenheit testen!
Ggf. dann noch zusätzlich per Kabelhai...

Vielen Dank für den Input!

@em-pie:
Danke auch für Deine Hinweise, aber ich habe die Geräte bereits bei meinen Tests neu gestartet bzw. aus- und wieder angeschalten, leider lag es daran nicht.

Im Zweifel immer über die onboard Paket Capture Funktion der OPNsense einmal die Ports UDP 67 und 68 (DHCP) am VLAN Interface der Firewall mitsniffern lassen und checken ob an der Firewall überhaupt DHCP Requests dieser beiden Endgeräte ankommen und wie die FW darauf reagiert sofern denn überhaupt etwas ankommt. (Im Zweifel mit dem PC verifizieren)
Kommen schon gar keine DHCP Requests dort an, liegt der Fehler davor.
Oftmals sind das Autonegotiation Fehler von Speed oder Duplex Mode am Switchport wie Kollege @PappaBaer2002 oben schon richtg angemerkt hat. Das bekommst du dann in der Regel mit einem statischen Speed und Duplex Eintrag am Switchport gefixt.

Die Geräte waren ja wohl vorher auf statischer IP.

Einfacher Test ist auch, sie an ein Netz zu stecken, wo es kein VLAN, nur DHCP gibt.

Also alte Fritz!Box und nur der Drucker oder Billo-Switch und Drucker+PC (auf PC dann einfacher DHCP-Server, z.B. www.dhcpserver.de/cms/), sonst nichts, dann sind alle übrigen Fehlerquellen schon einmal raus.

wo es kein VLAN, nur DHCP gibt.

Die Endgeräte merken doch rein gar nichts von einem VLAN und "sehen" nur ein LAN! 🤔
Wenn, dann die Firewall abziehen und in das entsprechende VLAN eine Fritte als DHCP Server stecken. Ansonsten kann z.B. ein Autonegotiation Fehler auf seinem Switch ja nicht verifiziert werden.

Alternativ kann er ganz einfach seinen PC auch ins gleiche VLAN klemmen wie die beiden Geräte und seinen Wireshark auf dem PC laufen lassen.
Sobald er die Geräte aktiviert muss dort ein DHCP Broadcast beider Geräte zu sehen sein.
Gibt halt mehrere Optionen das wasserdicht zu testen.

Die Endgeräte merken doch rein gar nichts von einem VLAN und "sehen" nur ein LAN! 🤔

Klar, keine Frage, aber in der "einfachsten" Form werden halt alle Fehlerquellen, so auch eine Falschkonfiguration im VLAN, ausgeschaltet.

Wenn es das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?

gelöst ist meine Problemstellung leider noch nicht.
Über die (von aqui empfohlene) Paket Capture-Funktion konnte ich nun eine .pcap-Datei erstellen.
Ich würde euch diese gerne hier zur Verfügung stellen, momentan weiß ich aber nicht wie ich diese bearbeitet bekomme um "überschüssige" Informationen noch zu entfernen bevor ich diese hier veröffentliche...

weiß ich aber nicht wie ich diese bearbeitet bekomme um "überschüssige" Informationen noch zu entfernen

Ganz einfach: Nutze den Display Filter indem du nur den relevanten Traffic anzeigen lässt.
Intelligenter wäre es gewesen du hättest schon gleich in der Paket Capture Option des Firewall GUIs den mitzuschneidenden Traffic auf die Ports UDP 67 und 68 beschränkt wie dir oben mehrfach gesagt wurde. Dann wäre auch nur dieser DHCP Traffic in die PCAP Datei geflossen und ein späteres Filtern wäre überflüssig.

Weitere hilfreiche Infos zu der Thematik auch hier:
https://www.heise.de/ratgeber/Fehler-erschnueffeln-221587.html

Sorry, gerade gesehen das das Packet Capture GUI in den Interface Diagnostics leider keine mehrfache Portangabe akzeptiert.

Es gibt aber einen pfiffigen Workaround mit dem man das schnell und einfach umgehen kann und der einem im Wireshark dann bilderbuchmässig den DHCP Ablauf zeigt!

SSH Zugang in den Firewall Settings aktivieren
Mit PuTTY oder dem SSH Client seiner Wahl auf der Firewall per SSH einwählen und im Auswahlmenü den Shell Zugang wählen
Hier kann man mit root@opnsense:~ # tcpdump -i igb0 -v port 67 or 68 einen Komandozeilen Sniffer starten und den Vorgang checken. ⚠️ Das Interface (hier igb0) muss man entsprechend auf sein spezifisches Interface einstellen WO man mitschneiden möchte. ifconfig gibt die Interface Namen aus.
Noch schöner ist es wenn man sich den Output gleich in eine fertige Wireshark Datei kopieren lässt die man dann in aller Ruhe mit dem Wireshark ansehen kann um den gesamten DHCP Vorgang (UDP Port 67 und 68) mitverfolgen zu können. Das geht mit:

root@opnsense:~ # tcpdump -i igb0 -v -s 65535 -w dhcp.pcap port 67 or 68

Dann kann man sich mit WinSCP (das es auch in einer bequem vom USB Stick startenden portablen Version gibt!) die Datei via Drag and Drop von der Firewall abholen

Und im Wireshark komplett ansehen. (Hier ein bootender Raspberry Pi der vom OPNsense DHCP Server die .101 vergeben bekommt)

Man sieht den klassischen Ablauf einer Bilderbuch DHCP Adressvergabe wie er z.B. HIER exakt beschrieben ist!

Fazit: Works as designed! 👍 😉

Wenn es das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?

Hallo nun endlich nochmal,

habe es soeben geschafft den von aqui formidabel beschriebenen Workaround durchzuführen (Danke für diese ausführliche Anleitung!). Anbei nun der gewünschte Screenshot aus dem Wireshark in der Hoffnung ihr könnt mir weitere Tipps geben.

Nochmal zum Verständnis meiner derzeitigen Situation:
Nachdem ich den Switch Port (Echt und Testport) Speedseitig auf 100M gestellt habe erhalte ich in meinem "Standard-Netz" (10.0.1.xxx) sauber eine DHCP-Adresse, wenn ich allerdings den Drucker in das dafür vorgesehene vlan (10.0.40.x) patche, dann klappt die Vergabe der IP nicht. Davor habe ich an den Switch-Port einen Windows-PC gepatcht, dieser erhält problemlos die DHCP-IP im 10.0.40.x-vlan aus dem dafür zur Verfügung stehenden Adresspool.

Der Drucker erhält Sie nicht, die Details dazu s. Screenshot aus Wireshark:

Moin,

in dem Screenshot sieht man zumindest, dass Dein Drucker das Discover schickt und der DHCP-Server mit einem Offer und der angebotenen IP-Adresse 10.0.40.121 antwortet.
Im nächsten Schritt müsste Dein Drucker nun wiederum das Request mit eben dieser angebotenen IP-Adresse senden. Macht er aber nicht, sondern fängt wieder von vorne mit einem Discover an.

Woran es hier nun hapert kann ich leider nicht erkennen, aber @aqui wird bestimmt nochmal hier antworten.

VG,
Torsten

Kollege @PappaBaer2002 hat es ja schon gesagt. Der böse Buhmann ist der Drucker, der müsste eigentlich mit einem ACK antworten. Warum er das nicht tut bleibt schleierhaft?
Für eine genauere Analyse müsste man mal 2 DHCP Vorgänge vergleichen. Einmal wo es klappt und einmal wo es scheitert und das genau betrachten.
Nur mal nebenbei gefragt: WELCHEN DHCP Server verwendest du auf der OPNsense?? Kea oder ISC?
Ggf. schon mal alternativ testweise den jeweils anderen aktiviert und mal gecheckt obs mit dem klappt?!
Sollte das Ergebnis gleich sein ist es de facto der Drucker.

Moin,

tippe auch auf den Drucker.
ich würde mal als erstes prüfen, ob es eine aktuelle Firmware gibt:
https://www.oki.com/de/printing/support/firmware/mono-multifunction/4576 ... (hoffe, es ist der richtige Drucker).
Dort mal alle ReleaseNotes sichten. Vielleicht ein bekanntes Problem, welches man zwischenzeitig behoben hat.

was allerdings gegen den Drucker spricht:

Wenn ich aber anschließend den Drucker oder die Heizung an den (zuvor erfolgreich getesteten) Port anschließe erhalte ich bei beiden Geräten keine IP per DHCP.

Moin,

und wie läuft das mit dem Drucker mit fester IP, eingestellt auf dem Drucker?

Zitat von @aqui:

Kollege @PappaBaer2002 hat es ja schon gesagt. Der böse Buhmann ist der Drucker, der müsste eigentlich mit einem ACK antworten. Warum er das nicht tut bleibt schleierhaft?
Für eine genauere Analyse müsste man mal 2 DHCP Vorgänge vergleichen. Einmal wo es klappt und einmal wo es scheitert und das genau betrachten.

Anbei der Screenshot des DHCP-Vorgangs aus dem 10.0.1.x (LAN) vlan (wo DHCP einwandfrei klappt):

Nur mal nebenbei gefragt: WELCHEN DHCP Server verwendest du auf der OPNsense?? Kea oder ISC?

Ich verwende bisher lediglich ISC DHCPv4.

Ggf. schon mal alternativ testweise den jeweils anderen aktiviert und mal gecheckt obs mit dem klappt?!
Sollte das Ergebnis gleich sein ist es de facto der Drucker.

Da die Frage in einem anderen Post noch war: die Firmware des Drucker ist die derzeit aktuellste (A01.84_0_4)

OK, beim ISC solltest du auch bleiben. Der Kea hat noch Kinderkrankheiten und ihm fehlen einige Funktionen.

wo DHCP einwandfrei klappt

Auch für den betroffenen Drucker?

Gibt es in dem Segment wo es nicht klappt ein anderes bzw. unterschiedliches Regelwerk im Vergleich zum Segment wo es klappt?
Sind die DHCP Server Settings für beide Segmente identisch und deren Adresspoolrange entsprechend limitiert das es keine Überschneidungen mit ggf. statischen Adressen gibt??

Zitat von @aqui:

OK, beim ISC solltest du auch bleiben. Der Kea hat noch Kinderkrankheiten und ihm fehlen einige Funktionen.

Alles klar.

wo DHCP einwandfrei klappt

Auch für den betroffenen Drucker?

Ja, genau. Der betroffene Drucker bekommt dort sauber eine DHCP-Adresse (habe ihm dort allerdings eine reserviert, aber spielt ja für die Thematik keine Rolle...)

* Gibt es in dem Segment wo es nicht klappt ein anderes bzw. unterschiedliches Regelwerk im Vergleich zum Segment wo es klappt?

Im Regelwerk gibt es keine offensichtlichen Unterschiede die hierfür eine Ursache sein könnten.

* Sind die DHCP Server Settings für beide Segmente identisch und deren Adresspoolrange entsprechend limitiert das es keine Überschneidungen mit ggf. statischen Adressen gibt??

Anbei 2 Screenshots der jeweiligen DHCP-Einstellungen:

Anbei 2 Screenshots der jeweiligen DHCP-Einstellungen:

Fehler ist dort der DNS Server und der Gateway Eintrag! Das ist unsinnig und überflüssig weil der DHCP Server diese immer automatisch mit den Firewall IP Adressen ersetzt wenn man sie LEER lässt! Die muss man nicht gesondert eintragen und solltest du besser löschen!
Orientiere dich an der Default DHCP Server Einstellung am Default LAN Interface dort ist das auch NICHT extra konfiguriert!

Zitat von @aqui:

Anbei 2 Screenshots der jeweiligen DHCP-Einstellungen:

Danke für die Hinweise!
Habe das nun sofort geändert, allerdings hat es dennoch nicht die entscheidende Änderung bewirkt (habe nach der Änderung den entsprechenden DHCP-Dienst auf der Sense natürlich noch neu gestartet), dass der Drucker nun sauber eine DHCP-Adresse erhält.

Mystisch.... 🤔
Leider hast du dein Regelwerk nicht gepostet so das da ggf. noch ein Fehler lauern könnte.

Ist das aber korrekt hilft dann wohl nur das Interface einmal komplett zu entfernen, aus dem Assignment rauszunehmen und es neu aufzusetzen.
DHCP Default und am Interface Regelwerk exakt die gleichen Regeln setzen wie die am funktionierenden Interface.

anbei noch das Regelwerk der beiden betroffenen (LAN=funktioniert , 40_Guest=problem) Netze:

Mmmhhh...
Hast du testweise mal versucht die "!RFC1918" Rule mal auf Source: 40_Guest_net Destination: ANY zu setzen also mal testweise alles zu erlauben wie oben im LAN, so das erstmal testweise ALLES durch darf??

Zudem ist die erste Regel auch noch völlig falsch und regeltechnisch unsinnig.

Sie erlaubt eingehend jegliche Absender IP mit einer Ziel IP die im gleichen Netz liegen.
Völlig unsinnig aus mehreren Gründen:

Lokaler Layer 2 Traffic im gleichen Netz kommt niemals bei der Firewall an! Logisch, denn der wird immer im Layer2 Mac Adress basierend behandelt. An der FW landet ausschliesslich nur Traffic der nicht lokal ist. Warum sollte so etwas an die Firewall als "Durchlauferhitzer" gehen?!
Man will niemals Absender IPs aus fremden IP Netzen an einem Interface sondern immer nur Absender die auch aus dem dortigen Netz kommen, also 40_Guest_net. Leute die da mit selbst ausgedachten IPs usw. rumfummeln will man nicht haben. Du erlaubst sowas?! Eben analog wie es am LAN Port auch konfiguriert ist. Sowas aufzumachen ist zu mindestens fahrlässig wenn man schon eine Firewall betreibt und Sicherheit will.
Abgesehen vom Obigen ist UDP für DNS over TLS zu definieren genauso fahrlässig denn DoT ist ausschliesslich nur für TCP 853 definiert! (Siehe HIER!)

Diese Regel ist also völliger Murks und unsinnig weil sie niemals einen Hit ergibt!
Warum erstellst du nicht zuallerst einmal ein Scheunentor was, wie am LAN, alles erlaubt, checkst alle deine Endgeräte Funktionen und machst danach die Schotten dicht?! Mit dieser sinvollen und strategischen Reihenfolge hast du bei einer Fehlfunktion doch immer Gewissheit das es NUR am Regelwerk liegen kann. Du aber gräbst dir zig Fallen und suchst danach mühsam den Fehler...unverständlich.
Solche "Regelwerk Leichen" haben auf einer vernünftig customizten Firewall nichts zu suchen!
Es macht immer Sinn VORHER einmal in aller Ruhe über das Regelwerk nachzudenken was man dort etablieren will und es dann umzusetzen!
Ein Gastnetz aktiviert man so oder so immer mit einem Captive Portal an der Firewall um juristisch nicht angreifbar zu sein und die User zu mindestens mit ihren Mac Adressen mitprotokolliert!
Grundregeln wie immer:

Regeln sollten immer nur inbound definiert sein!
Es gilt: "First match wins". Sprich der erste "Hit" im Regelwerk bewirkt das der Rest der Regeln NICHT mehr abgearbeitet wird!
Default am Ende ist Firewall üblich: DENY any any

Zitat von @aqui:

Mmmhhh...
Hast du testweise mal versucht die "!RFC1918" Rule mal auf Source: 40_Guest_net Destination: ANY zu setzen also mal testweise alles zu erlauben wie oben im LAN, so das erstmal testweise ALLES durch darf??

Habe ich eben getestet, allerdings gleiches Ergebnis => kein DHCP IP im vlan 40_Guest

Zudem ist die erste Regel auch noch völlig falsch und regeltechnisch unsinnig.

Welche der beiden Regeln meinst Du damit jetzt?

Sie erlaubt eingehend jegliche Absender IP mit einer Ziel IP die im gleichen Netz liegen.
Völlig unsinnig aus mehreren Gründen:

Lokaler Layer 2 Traffic im gleichen Netz kommt niemals bei der Firewall an! Logisch, denn der wird immer im Layer2 Mac Adress basierend behandelt. An der FW landet ausschliesslich nur Traffic der nicht lokal ist. Warum sollte so etwas an die Firewall als "Durchlauferhitzer" gehen?!
Man will niemals Absender IPs aus fremden IP Netzen an einem Interface sondern immer nur Absender die auch aus dem dortigen Netz kommen, also 40_Guest_net. Leute die da mit selbst ausgedachten IPs usw. rumfummeln will man nicht haben. Du erlaubst sowas?!

Verstehe ich nicht wirklich, was Du damit meinst.

Die obere Regel ist für DNS und die untere besagt ja lediglich dass die Gast-Netz-IPs überall hin dürfen (Internet) aber nicht ins lokale LAN.

Eben analog wie es am LAN Port auch konfiguriert ist. Sowas aufzumachen ist zu mindestens fahrlässig wenn man schon eine Firewall betreibt und Sicherheit will.
Abgesehen vom Obigen ist UDP für DNS over TLS zu definieren genauso fahrlässig denn DoT ist ausschliesslich nur für TCP 853 definiert! (Siehe HIER!)

Hier habe ich lediglich bei der Protokoll-Auswahl das falsche aus dem Drop-Down ausgewählt, habe dies aber soeben direkt korrigiert (=>nur noch TCP).

Evtl. wäre das nochmal sinnvoll!
Ich habe halt nach bestem Wissen und Gewissen aus verschiedenen Quellen angefangen mir das alles so aufzubauen wie ich es dann für sinnvoll und am besten gehalten hatte...Grundlegend funktioniert soweit ja auch alles, ich habe lediglich mit den hier genannten Geräten ein verhalten was nicht "as designed" reagiert...

Solche "Regelwerk Leichen" haben auf einer vernünftig customizten Firewall nichts zu suchen!
Es macht immer Sinn VORHER einmal in aller Ruhe über das Regelwerk nachzudenken was man dort etablieren will und es dann umzusetzen!
Ein Gastnetz aktiviert man so oder so immer mit einem Captive Portal an der Firewall um juristisch nicht angreifbar zu sein und die User zu mindestens mit ihren Mac Adressen mitprotokolliert!
Grundregeln wie immer:

Regeln sollten immer nur inbound definiert sein!
Es gilt: "First match wins". Sprich der erste "Hit" im Regelwerk bewirkt das der Rest der Regeln NICHT mehr abgearbeitet wird!
Default am Ende ist Firewall üblich: DENY any any

Hi!

Zitat von @Seggel:
Ja, genau. Der betroffene Drucker bekommt dort sauber eine DHCP-Adresse (habe ihm dort allerdings eine reserviert, aber spielt ja für die Thematik keine Rolle...)

Mach diese Reservierung mal testweise raus. Nicht, dass die OPNsense dem Drucker dann verweigert eine andere IP in einem anderen Subnetz zu geben (weil reserviert)

Zitat von @Seggel:
Welche der beiden Regeln meinst Du damit jetzt?

Schau dir mal die erste Regel an. Macht die "wirklich" Sinn? Destination...

MfG

Verstehe ich nicht wirklich, was Du damit meinst.

Lokaler IP Traffic zwischen 2 oder mehr Geräten innerhalb des gleichen Netzwerkes kommt doch niemals an der Firewall an!!
Wenn du 2 PCs hast in dem Netz können die doch auch komplett OHNE Firewall miteinander kommunizieren. Die brauchen dafür nur ihre Mac Adressen.
Oder dachtest du nur weil eine Firewall ins Netz gestöpselt ist geht auch lokaler Traffic zwischen diesen 2 Rechnern mt einmal von Geisterhand über die Firewall?!
In sofern ist doch ein Regelwerk wie das DoT was z.B. IP Pakete aus diesem Netz (Source) an Zieladressen aus diesem gleichen Netz (Destination) reglementiert vollkommener Unsinn, weil diese IPs niemals an der Firewall und damit am Regelwerk ankommen. Solche Regel ist überflüssiger Murks, weil die niemals greift.
Das sagt einem aber doch auch der gesunde IT (oder I"P") Verstand!

Was ist daran so schwer zu verstehen?

Die obere Regel ist für DNS

Das ist schon klar, nur eben totaler Unsinn wenn die Destination Adresse gleich ist dem Netzwerk aus dem die Pakete kommen. Kollege @support-m hat es oben schon richtig gesagt. Mal abgesehen davon das UDP auch falsch ist bzw. war.
Es kann also nur DoT Traffic von den Clients nach extern (Internet) sein, da die Firewall selber kein DoT kann.
Das wird aber doch schon durch deine globale Regel die allen nicht RFC1918 Traffic AUS dem 40er Gastnetz nach ANY erlaubt schon gleich mit abgefackelt. Die DoT Regel ist also damit vollkommen überflüssig da völlig ohne jegliche Funktion. Pakete die diese Regel matchen kommen dort niemals an in sofern kannst du sie auch gleich komplett löschen.

die untere besagt ja lediglich dass die Gast-Netz-IPs überall hin dürfen (Internet) aber nicht ins lokale LAN.

Die wäre ja auch richtig.
Hier wäre nur einmal sinnvoll zu testen ob das RFC1918 Blocking ggf. Einfluss auf das DHCP Verhalten hat, denn das ist ja der signifikante Unterschied zum LAN Interface wo ja alles fehlerlos rennt. Quasi also einfach mal die LAN Regel auf das 40er Netz klonen so das man identische Bedingungen an beiden Interfaces hat!

aus verschiedenen Quellen

Oha... wenn diese dir solche Gruselregeln wie beim DoT vorgegeben haben muss man sich nicht groß wundern...

Wenn es das denn nun war als Lösung bitte nicht vergessen deinen Thread hier dann auch als erledigt zu schliessen!
Wie kann ich einen Beitrag als gelöst markieren?

Hallo miteinander,

vielen Dank für eure hilfreiche Unterstützung!
Die Ursache für mein Problem lag an der VLAN-Konfiguration des Switches, hier waren tagged und untagged-Ports nicht einwandfrei konfiguriert was dann zu den Problemen geführt hat.

Nach der Korrektur (Switchseitig) funktioniert alles wie gewünscht/as designed

Danke euch allen!

LG
Seggel