6
Konfiguration von VLANs auf einer SophosUTM 9.2 in der Testumgebung
Hallo Zusammen,
folgende Konfiguration habe ich momentan in einer Testumgebung aufgebaut:
Hardware:
Switch01 (HP 1810-48G)
SophosUTM 9.2 (auf Hyper-V; NIC1 und NIC2 zugewiesen; NIC2 ist in Hyper-V-Konfiguration VLAN 5 zugewiesen)
Fogender Aufbau:
Switch01:
Port 1 -24 --> In VLAN1 UNTAGGED
Port 25-47 --> In VLAN5 UNTAGGED
Port 48 --> In VLAN5 TAGGED
Auf der Sophos UTM sind 2 Intefaces konfiguriert:
Eth1 --> Ethernet Statisch; 192.168.1.1/24; Hardware=NIC1; verbunden mit Port 1 an Switch01
Eth2 --> Ethernet VLAN; 192.168.5.1; VLAN TAG 5; Hardware=NIC2; verbunden mit Port 48 an Switch01
Ziel ist es jetzt, mit einem Client von den Ports 25-47 mit der Schnittstelle Eth2 der SophosUTM zu kommunizieren. Was aber nicht funktioniert - DHCP-Requests bleiben (trotz für das Netzwerk von Eth2 konfiguriertem DHCP auf der SophosUTM) unbeantwortet. Bei Statischer IP-Adresse des Clients kommt kein Ping beim StandardGateway (Eth2) an.
Kann sich von Euch jemand vorstellen woran das liegt? Ideen zum weiteren Troubleshooting? Bin jetzt schon seit 2 Tagen am rumprobieren und mit meinem Latein langsam am Ende.
Vielen Dank für die Hilfe, vorab!
Grüße,
J.D.
folgende Konfiguration habe ich momentan in einer Testumgebung aufgebaut:
Hardware:
Switch01 (HP 1810-48G)
SophosUTM 9.2 (auf Hyper-V; NIC1 und NIC2 zugewiesen; NIC2 ist in Hyper-V-Konfiguration VLAN 5 zugewiesen)
Fogender Aufbau:
Switch01:
Port 1 -24 --> In VLAN1 UNTAGGED
Port 25-47 --> In VLAN5 UNTAGGED
Port 48 --> In VLAN5 TAGGED
Auf der Sophos UTM sind 2 Intefaces konfiguriert:
Eth1 --> Ethernet Statisch; 192.168.1.1/24; Hardware=NIC1; verbunden mit Port 1 an Switch01
Eth2 --> Ethernet VLAN; 192.168.5.1; VLAN TAG 5; Hardware=NIC2; verbunden mit Port 48 an Switch01
Ziel ist es jetzt, mit einem Client von den Ports 25-47 mit der Schnittstelle Eth2 der SophosUTM zu kommunizieren. Was aber nicht funktioniert - DHCP-Requests bleiben (trotz für das Netzwerk von Eth2 konfiguriertem DHCP auf der SophosUTM) unbeantwortet. Bei Statischer IP-Adresse des Clients kommt kein Ping beim StandardGateway (Eth2) an.
Kann sich von Euch jemand vorstellen woran das liegt? Ideen zum weiteren Troubleshooting? Bin jetzt schon seit 2 Tagen am rumprobieren und mit meinem Latein langsam am Ende.
Vielen Dank für die Hilfe, vorab!
Grüße,
J.D.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 247062
Url: https://administrator.de/contentid/247062
Printed on: April 19, 2024 at 15:04 o'clock
6 Comments
Latest comment
Der Teufel liegt bei den billigen HP Gurken hier im Detail !
Generell ist deine Konfig richtig und korrekt so und sollte auch so funktionieren. Was du unbedingt vorher testen solltest ist das die interne Kommunikation im VLAN auch klappt indem man dort mal 2 Endgeräte sich pingen lässt.
Vermutlich macht deine UTM kein VLAN Tagging und "versteht" so die VLAN 5 Packete nicht. Auch das solltest du sicher checken. Im Zweifel hängst du einen Wireshark dran und siehst dir an ob die VLAN 5 Packete dort mit einer tag ID von 5 auch ankommen.
Du kannst das auch mit einem simplen Rechner querchecken der eine Netzwerkkarte hat die Tagging supportet wie Intel Chips z.B.
Dort kannst du dann mal Tagging aktivieren und so das Verhalten des Switches wasserdicht verifizieren.
Wie das geht steht hier:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Es lauert aber noch eine ganz andere Gefahr !
Die HP Switches übertragen auf einem tagged Uplink immer auch das Default VLAN 1 untagged. Der IEEE 802.1q Standard lässt das zu und HP hat Tagged Uplinks so implementiert.
Vermutlich macht das die UTM auch, denn auch bei Endgeräten ist das mehr oder minder etablierter Standard auf tagged Links, das dort immer auch untagged das VLAN 1 anliegt.
Jetzt hast du aber auch einen dedizierten VLAN 1 Link an der UTM und das diese HP 1800er Billiggurken kein Spanning Tree supporten zur Loopvermeidung ist es möglich das du dort unbewusst ein Loop geschaltet hast.
Auch das solltest du nochmal genau verifizieren.
Andersrum wenn der UTM z.B. Spanning Tree supportet kann es sein das der den Port Eth2 in den Blocking Mode nimmt und so diesen Link abhängt.
HP kann generell kein Per VLAN Spanning Tree sondern kann nur das dumme Single Span Verfahren was nicht zwischen VLANs unterscheiden kann. Geht also ein Link in den Blocking Mode tut es der ganze Link egal welche und wieviele VLANs drauf sind.
Das solltest du alles mal checken.
Generell kannst du hier in diesem Tutorial nachlesen wie so eine Konfig (Beispiel pfSense) auszusehen hat inkl. der zugehörigen Switchkonfig bei HP.
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Generell ist deine Konfig richtig und korrekt so und sollte auch so funktionieren. Was du unbedingt vorher testen solltest ist das die interne Kommunikation im VLAN auch klappt indem man dort mal 2 Endgeräte sich pingen lässt.
Vermutlich macht deine UTM kein VLAN Tagging und "versteht" so die VLAN 5 Packete nicht. Auch das solltest du sicher checken. Im Zweifel hängst du einen Wireshark dran und siehst dir an ob die VLAN 5 Packete dort mit einer tag ID von 5 auch ankommen.
Du kannst das auch mit einem simplen Rechner querchecken der eine Netzwerkkarte hat die Tagging supportet wie Intel Chips z.B.
Dort kannst du dann mal Tagging aktivieren und so das Verhalten des Switches wasserdicht verifizieren.
Wie das geht steht hier:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Es lauert aber noch eine ganz andere Gefahr !
Die HP Switches übertragen auf einem tagged Uplink immer auch das Default VLAN 1 untagged. Der IEEE 802.1q Standard lässt das zu und HP hat Tagged Uplinks so implementiert.
Vermutlich macht das die UTM auch, denn auch bei Endgeräten ist das mehr oder minder etablierter Standard auf tagged Links, das dort immer auch untagged das VLAN 1 anliegt.
Jetzt hast du aber auch einen dedizierten VLAN 1 Link an der UTM und das diese HP 1800er Billiggurken kein Spanning Tree supporten zur Loopvermeidung ist es möglich das du dort unbewusst ein Loop geschaltet hast.
Auch das solltest du nochmal genau verifizieren.
Andersrum wenn der UTM z.B. Spanning Tree supportet kann es sein das der den Port Eth2 in den Blocking Mode nimmt und so diesen Link abhängt.
HP kann generell kein Per VLAN Spanning Tree sondern kann nur das dumme Single Span Verfahren was nicht zwischen VLANs unterscheiden kann. Geht also ein Link in den Blocking Mode tut es der ganze Link egal welche und wieviele VLANs drauf sind.
Das solltest du alles mal checken.
Generell kannst du hier in diesem Tutorial nachlesen wie so eine Konfig (Beispiel pfSense) auszusehen hat inkl. der zugehörigen Switchkonfig bei HP.
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Erstmal vielen Dank!
es ist also gut möglich, dass der Fehler darin liegt, dass ich die UTM ja virtualisiert in der Testumgebung betreibe und die Netzwerkadapter ja lediglich USB-Netzwerkkarten sind, welche in die Virtualisierung eingebunden wurden. Entscheident wäre hier zu wissen: muss die UTM (Software) VLAN-Tagging können oder müssen es tatsächlich die Netzwerkkarten sein? Ich kann mir natürlich gut vorstellen, dass die USB-NICs das nicht können.
Ich meine etwas davon gelesen zu haben, dass die UTM VLAN1 nutzt, das wäre also auch ein Ansatz, auch wenn ich momentan noch nicht weiß, wie ich das Problem dann lösen sollte.
es ist also gut möglich, dass der Fehler darin liegt, dass ich die UTM ja virtualisiert in der Testumgebung betreibe und die Netzwerkadapter ja lediglich USB-Netzwerkkarten sind, welche in die Virtualisierung eingebunden wurden. Entscheident wäre hier zu wissen: muss die UTM (Software) VLAN-Tagging können oder müssen es tatsächlich die Netzwerkkarten sein? Ich kann mir natürlich gut vorstellen, dass die USB-NICs das nicht können.
Ich meine etwas davon gelesen zu haben, dass die UTM VLAN1 nutzt, das wäre also auch ein Ansatz, auch wenn ich momentan noch nicht weiß, wie ich das Problem dann lösen sollte.
ja lediglich USB-Netzwerkkarten sind, welche in die Virtualisierung eingebunden wurden
Generell ist das kein Thema, da so gut wie alle USB Netzwerkkarten 802.1q VLAN Tagging supporten wie du z.B. hier:Netzwerk Management Server mit Raspberry Pi
Beim Thema bzw. Kapitel Tagging und VLAN nachlesen kannst.
USB NICs können das also in aller Regel problemlos. Diese Adapter basieren allesamt auf dem ASIX AX88772 oder bei USB 3 auf dem neueren AX88179 Chip die alle .1q Tagging supporten. Das ist also sicher nicht das Problem !
Die Frage ist ob die Virtualisierungssoftware das wirklich auch an die Physik durchreicht ??
Das kannst du aber ganz einfach mal testen indem du mit einem Crossover Kabel mal einen Wireshark direkt an den Eth2 des UTM anschliesst und ein paar Pings raussendest dort.
Der Wireshark müsste dir diese Ping Requests bzw. den davor zu machenden ARP Request der UTM ja immer als Tagged Paket mit der VLAN ID 5 anzeigen.
Damit gehtst du ganz sicher ob die UTM sich da konform verhält bzw. ob der Hypervisor diese Frames auch so korrekt an die NIC Physik weitereicht.
Das ist schnell zu machen und schafft Sicherheit ür dich !
Zu dem Thema Firewall Appliances in virtuellen Umgebungen wollen wir jetzt mal nichts sagen... Eigentlich ein NoGo aber auch nicht das Thema hier.
Ok, schade wäre ja auch zu einfach gewesen 
Dass die virtualisierung das Problem ist, könnte durchaus sein - im Übrigen ist die Firewall Appliance nur für meine Tests virtuallisiert! In der produktiven Umgebung ist es eine Hardware.
Ich werd mal weiter testen und dann meld ich mich wieder.
Danke für die Hilfe!
Dass die virtualisierung das Problem ist, könnte durchaus sein - im Übrigen ist die Firewall Appliance nur für meine Tests virtuallisiert! In der produktiven Umgebung ist es eine Hardware.Ich werd mal weiter testen und dann meld ich mich wieder.
Danke für die Hilfe!
Es kann eigentlich nur irgendwie der Hypervisor sein.
Das Problem gibt es auch übrigens bei älteren Netzwerkkarten oder älteren Ethernet Chipsätzen die keinen sog. Promiscous Mode supporten. Dieser ist aber essentiell wichtig um 802.1q getaggte Frames zu übertragen, da der .1q Standard den Ethernet Frame erweitert.
Wie gesagt, nimm einfach den kostenlosen Wireshark zur Hand und miss das mal schnell nach. Das dauert 5 Minuten und du hast dann aber Gewissheit und musst nicht blind nach Trial and Error verfahren
Das Problem gibt es auch übrigens bei älteren Netzwerkkarten oder älteren Ethernet Chipsätzen die keinen sog. Promiscous Mode supporten. Dieser ist aber essentiell wichtig um 802.1q getaggte Frames zu übertragen, da der .1q Standard den Ethernet Frame erweitert.
Wie gesagt, nimm einfach den kostenlosen Wireshark zur Hand und miss das mal schnell nach. Das dauert 5 Minuten und du hast dann aber Gewissheit und musst nicht blind nach Trial and Error verfahren
Es war der Hypervisor. Hab die UTM auf einer ausgemusterten HP-Kiste installiert und es funktionierte dort sowohl über die USB-Karte als auch über die interne NIC.
Vielen Dank für die Hilfe, aqui!!
Vielen Dank für die Hilfe, aqui!!
