02.07.2018

2031

VLANs mit der UTM9 und einem 3 Com Switch

Hallo zusammen,

ich möchte Testweise auf eine Sperate ETH auf der UTM einen alten 3 Comk switch stecken und dort 2 VLANs bilden.
Generell müsste ich doch dazu 2 Ethernet VLAN interfaces auf der UTM erstellen und diese dann Tagged an einen Port des 3Com Switches? Wie sieht es dann mit DHCP aus? der Switch ist nu Layer 2.

Hin und Rückrouten sind bereits gesetzt, da Gateway nicht die UTM ist. Über eine reine Ethernet Schnittstelle funktioniert die Verbindung, aber nicht über eine EthernetVLAN Schnittstelle.

Besten Dank für Tipps!

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

Content-ID: 378891

Url: https://administrator.de/forum/vlans-mit-der-utm9-und-einem-3-com-switch-378891.html

Ausgedruckt am: 01.04.2025 um 08:04 Uhr

18 Kommentare

Neuester Kommentar

Hallo,

Zitat von @Leo-le:
einen alten 3 Comk switch stecken und dort 2 VLANs bilden.

Kann dein ungenannter 3COM denn überhaupt VLAN? HP hat 2010 3COM komplett übernommen bzw. den namen 3COM eingestellt.

Gruß,
Peter

Generell müsste ich doch dazu 2 Ethernet VLAN interfaces auf der UTM erstellen und diese dann Tagged an einen Port des 3Com Switches?

Ja, das ist richtig !
Wie gesagt wenn die 3Com Gurke 802.1q fähig ist (VLAN Support)

Wie sieht es dann mit DHCP aus? der Switch ist nu Layer 2.

Davon sind auch wir ausgegangen.
Die Frage ist unverständlich

Was meinst du damit.
Deine L3 Interfaces in den VLANs sind ja die der UTM. Also entweder machen die dann pro VLAN DHCP oder, sofern du einen zentralen DHCP Server hast der diese VLANs mitversorgt, dann musst du auf diesen Interfaces einen DHCP Relay Server eintragen. Fertsch !

Hin und Rückrouten sind bereits gesetzt, da Gateway nicht die UTM ist.

Auch das ist sehr verwirrend...

WO soll denn das UTM nicht das Gateway sein ? Ja sicher NICHT in den beiden neuen VLANs, denn da sind ja die UTM Interfaces ja die einzigen L3 Interfaces in den Rest der Welt.
Vermutlich meinst du das in den Zielnetzen die UTM nicht das Gateway ist, richtig ?
Dann sind auf den Gateway Rechnern natürlich statische Routen für diese beiden neuen VLAN Netze (oder eine Summary Route) via UTM erforderlich, das ist richtig !
Bedenke auch das die UTM eine Firewall ist !
Du musst also auf den beiden neuen VLAN Interfaces und auch auf dem Interfaces was die Zielnetze bedient eine entsprechende Firewall Regel existieren muss die diesen Traffic passieren lässt.
Grundlagen dazu auch hier:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern

Zitat von @Pjordorf:

Hallo,

Zitat von @Leo-le:
einen alten 3 Comk switch stecken und dort 2 VLANs bilden.

Kann dein ungenannter 3COM denn überhaupt VLAN? HP hat 2010 3COM komplett übernommen bzw. den namen 3COM eingestellt.

Gruß,
Peter

Ja, dass habe ich zuvor schon gecheckt.

Wie sieht es dann mit DHCP aus? der Switch ist nu Layer 2.

Davon sind auch wir ausgegangen.
Die Frage ist unverständlich

Okay, also DHCP über die UTM interfaces, das wollte ich nur nochmal bestätigt haben. Besten Dank!

Hin und Rückrouten sind bereits gesetzt, da Gateway nicht die UTM ist.

Auch das ist sehr verwirrend...

Unser Hauptgateway ist die Checkpoint Firewall und die SOphos wird reinweg als Mailproxy und WebProtection Proxy verwendet.
Hier habe ich die Route auf der Checkpoint Firwall in das Netz des VLANs geroutet.

WO soll denn das UTM nicht das Gateway sein ? Ja sicher NICHT in den beiden neuen VLANs, denn da sind ja die UTM Interfaces ja die einzigen L3 Interfaces in den Rest der Welt.

Das ist klar soweit.

Vermutlich meinst du das in den Zielnetzen die UTM nicht das Gateway ist, richtig ?

Nein, die UTM ist nicht als Gateway auf den Clients eingetragen, denn dort steht die IP der Checkpoint FW.

Dann sind auf den Gateway Rechnern natürlich statische Routen für diese beiden neuen VLAN Netze (oder eine Summary Route) via UTM erforderlich, das ist richtig !
Bedenke auch das die UTM eine Firewall ist ! Ist bei uns nicht als FW aktiv.
Du musst also auf den beiden neuen VLAN Interfaces und auch auf dem Interfaces was die Zielnetze bedient eine entsprechende Firewall Regel existieren muss die diesen Traffic passieren lässt.

Okay, besten Dank! Eines ist mir dennoch nicht ganz klar...

Ich steck den 3 com Siwtch an den Sophos Port 5 und erstelle ein Ethernet interface auf der UTM und vergebe einen anderen Netzbereich, soweit sogut. Switch ist aus meinem Netz erreichbar. Jetzt möchte ich aber zumindest erst einmal ein VLAN konfigurieren. Dazu erstelle ich ein Ethernet VLAN Schnittstelle auf der UTM9 und konfiguriere den Port am Switch als ein Tagged Port, um dort mehrere VLANs auf den einen Port zu betreiben? Das ist mir noch nicht so richtig klar...

Grundlagen dazu auch hier:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern

Top, das führe ich mich jetzt mal zur gemüte.

Der Port 5 der Sophos ist dann tagged und auch der Switchport.
So erkennen beide Seiten sofort anhand der VLAN ID (Tag) in den Paketen für welches VLAN die Pakete gedacht sind.
Anhand des VLAN Tags kann dann einerseits die Sophos diese Pakete ihrem VLAN Interface am physischen Port 5 zuordnen und der Switch weiss genau in welches VLAN er diese Pakete forwarden muss.
Eigentlich ganz einfach und simpel...

Ggf. hilft dir noch die "VLAN Schnellschulung" damit alle Klarheiten beseitigt sind ?!
Heimnetzwerk Aufbauen oder auch wie wird ein Longshine LCS-GS8408 eingerichtet

Zitat von @aqui:

Der Port 5 der Sophos ist dann tagged und auch der Switchport.
So erkennen beide Seiten sofort anhand der VLAN ID (Tag) in den Paketen für welches VLAN die Pakete gedacht sind.
Anhand des VLAN Tags kann dann einerseits die Sophos diese Pakete ihrem VLAN Interface am physischen Port 5 zuordnen und der Switch weiss genau in welches VLAN er diese Pakete forwarden muss.
Eigentlich ganz einfach und simpel...

Ggf. hilft dir noch die "VLAN Schnellschulung" damit alle Klarheiten beseitigt sind ?!
Heimnetzwerk Aufbauen oder auch wie wird ein Longshine LCS-GS8408 eingerichtet

Vielen Dank aqui, das funktioniert jetzt auch soweit. Nun möchte ich aber ja eine Firewallregel erstellen, wo nur bestimmte User Zugriff auf eines der VLANs hat. Also erstelle ich z.B. eine Regel, wo alle Dienste von meinem Rechner auf das VLAN20 Netzwerk gedropt werden.
Alles soweit klar, jedoch habe ich trotz dieser Regel auf Position 1 Zugriff auf das VLAN 20. Liegt das zufällig daran, dass mein Rechner als Gateway die .220 hat und die Sophos die .254 und auf der Sophos die VLANs konfiguriert sind?

das funktioniert jetzt auch soweit.

So sollte es auch sein

Also erstelle ich z.B. eine Regel, wo alle Dienste von meinem Rechner auf das VLAN20 Netzwerk gedropt werden.

Ja, ganz genau. Wenn dein Rechner im VLAN 10 (10.1.10.0 /24) die Hostadresse 100 hat sieht das so aus:
DENY host 10.1.10.100 10.1.20.0
PERMIT 10.1.10.0 /24 ANY
Das verbietet deinen Rechner aufs VLAN 20 erlaubt aber den ganzen Rest
Diese Access Liste bindest du nun an das VLAN Interface und gut iss.

jedoch habe ich trotz dieser Regel auf Position 1 Zugriff auf das VLAN 20.

Da ist di Sache dann klar, dann hast du ganz sicher einen Fehler in der Access Listen Syntax gemacht !
Ein Screenshot deiner Regel am VLAN 10 Port (wo dein Rechner ist) wäre hier mal sehr hilfreich gewesen für eine zeilführende Hilfe. Leider hats dafür ja nicht gereicht

Bleibt uns also nur die Glaskugel !

Liegt das zufällig daran, dass mein Rechner als Gateway die .220 hat und die Sophos die .254

Ja, das ist der Grund !
Du "umgehst" ja quasi die Sophos. Deine Pakete ins VLAN 20 kommen da niemals an. Es sei denn...
Du hast auf dem Gateway mit der .220 eine statische Route auf die Sophos definiert:
Ziel: <vlan_x_netz> <maske> Gateway: x.y.z.254
Dann wäre das natürlich wieder richtig !

Aus Layer 3 (Routing) Sicht sähe das dann so aus wenn es richtig ist:

Hey Aqui,

vielen Dank für dein excelenten Support!
Soweit ist alles gut, bloß greifen meine Regeln nicht auf der Sophos. ( Bin mir ziemlich sicher, dass diese richtig sind)
Der Verkehr muss ja durch die Sophos gehen, wenn ein Port ETH2 internal ist und Port 5 der Switch mit den VLANs?
Ich kann nach wie vor darauf zugreifen.

Zitat von @aqui:

das funktioniert jetzt auch soweit.

So sollte es auch sein

Also erstelle ich z.B. eine Regel, wo alle Dienste von meinem Rechner auf das VLAN20 Netzwerk gedropt werden.

Ja, ganz genau. Wenn dein Rechner im VLAN 10 (10.1.10.0 /24) die Hostadresse 100 hat sieht das so aus: DENY host 10.1.10.100 10.1.20.0
PERMIT 10.1.10.0 /24 ANY
Das verbietet deinen Rechner aufs VLAN 20 erlaubt aber den ganzen Rest
Diese Access Liste bindest du nun an das VLAN Interface und gut iss.

jedoch habe ich trotz dieser Regel auf Position 1 Zugriff auf das VLAN 20.

Bleibt uns also nur die Glaskugel !

Liegt das zufällig daran, dass mein Rechner als Gateway die .220 hat und die Sophos die .254

Ja, das ist der Grund !
Du "umgehst" ja quasi die Sophos. Deine Pakete ins VLAN 20 kommen da niemals an. Es sei denn...
Du hast auf dem Gateway mit der .220 eine statische Route auf die Sophos definiert: Ziel: <vlan_x_netz> <maske> Gateway: x.y.z.254
Dann wäre das natürlich wieder richtig !

Klar, ich habe auf der Checkpoint eine Route erstellt, sowie auch auf der Sophos.

Aus Layer 3 (Routing) Sicht sähe das dann so aus wenn es richtig ist:

Ich kann nach wie vor darauf zugreifen.

Die UTM Regel ist anhand des Screenshots leider nicht zu erkennen um zu prüfen ob sie syntaktisch richtig ist.
Vermutlich ist sie das NICHT wenn du weiterhin Endgeräte im geblockten VLAN erreichen kannst.

Nehmen wir mal ein Beispiel:
Gelten soll deine Regel: "wo nur bestimmte User Zugriff auf eines der VLANs hat. Also erstelle ich z.B. eine Regel, wo alle Dienste von meinem Rechner auf das VLAN20 Netzwerk gedropt werden."
Also:

Dein Rechner ist der im 10.1.1.0er Netz mit der IP .100
Dein Rechner hat als Gateway die .220, Routing in VLAN 1 und 2 klappt ohne Regel fehlerfrei.
VLAN 2 oben hat die 10.2.2.0 /24
Dieser Rechner darf NICHT ins VLAN 2
Er darf aber ins VLAN 1 (10.11.11.0 /24)

Damit muss an das Ethernet Interface der UTM die die IP 10.1.1.254 /24 hat folgende INBOUND Regel:
DENY Source IP= Host 10.1.1.100 /32, Destination IP=10.2.2.0 /24
PERMIT Source IP=10.1.1.0 /24, Destination IP= ANY
Fertisch.
Damit blockt die UTM dann deinen Rechner (.100) der aus 10.1.1.0er Netz reinkommt und zum 10.2.2.0er Netz will
Alles was vom vom 10.1.1.0er Netz reinkommt und auf andere IPs will darf passieren.
Für jedes VLAN bzw. Host aus dem 10.1.1.0er Netz was verboten werden soll machst du einen weiteren Eintrag dort. Aber bitte VOR der Permit Regel !!
Reihenfolge zählt hier !! (First match wins Regel !)
Damit klappt das fehlerfrei. Getestet hier mit einer pfSense Firewall.

Hallo aqui,

vielen Dank für deinen Support!
Soweit ist alles klar, seltsamerweise greifen eben die Regeln nicht.
Aufgebaut ist alles wie auf deiner Netzwerkskizze...

Insgesamt gehe ich doch auf den Reiter Firewall und trage z.B. als Source meinen Rechner ein mit. ( IP Stimmt und ist geprüft)
Als Services gebe ich Any an und als Destination das VLAN20 und das VLAN10 bzw. Management VLAN, die ich als Schnittstellen auf der UTM eingerichtet habe. Wenn ich nun noch als umgekehrt Source das VLAN 20 nehme und als Dienst Any, sowie als Desti. meinen Rechner, dann dürfte ich doch auf keinen Fall mehr Zugriff auf das VLAN 20 von meinen Rechner aus haben? Die Regel steht ganz oben auf Position 2 . Position eins ist ein VPN-Pool.

Hallo,

Zitat von @Leo-le:
Insgesamt gehe ich doch auf den Reiter Firewall

Deine UTM?

und trage z.B. als Source meinen Rechner ein mit. ( IP Stimmt und ist geprüft)...

Damit hast du dir Zugriff gewährt oder ist es eine Deny Regel? Was sagt denn das Firewall Protokll (Echtezeit) ist dort dein Zugriff zu sehen und ist der Rot? Wenn der nicht zu sehen ist, wer routet dann zwischen deine VLANs oder machst du http Anfragen und die laufen durch ein Proxy?

Wenn ich nun noch als umgekehrt Source das VLAN 20 nehme und als Dienst Any, sowie als Desti. meinen Rechner

Warum?

Mach ein Protokollierung deiner Regeln und dann solltest du sehen wer was mit wem usw.

Gruß,
Peter

Zitat von @Pjordorf:

Hallo,

Zitat von @Leo-le:
Insgesamt gehe ich doch auf den Reiter Firewall

Deine UTM?

UTM9 SG230

und trage z.B. als Source meinen Rechner ein mit. ( IP Stimmt und ist geprüft)...

deny Regel

Wenn ich nun noch als umgekehrt Source das VLAN 20 nehme und als Dienst Any, sowie als Desti. meinen Rechner

Warum?

Ja, ist käse, aber spätestens dann dürfte doch definitv kein Zugriff mehr sein.

Mach ein Protokollierung deiner Regeln und dann solltest du sehen wer was mit wem usw.

Ich prüfe jetzt noch einmal das Protokoll von der Sophos, aber ich sehe dort meine Anfragen auf die Sophos seltsamerweise nicht.

Gruß,
Peter

Hallo,

Zitat von @Leo-le:
UTM9 SG230

Und welche Module laufen dort bzw. sind Lizenziert und aktiviert. Firewall ist ja nur ein kleiner Teil einer Sophos SG UTM?

deny Regel

aber ich sehe dort meine Anfragen auf die Sophos seltsamerweise nicht.

Dann wird deine Sophos entweder umgangen oder du nutzt nicht deren Firewall oder du hast nicht gesagt das diese regel Protokolliert werden soll (Standard) Edit Rule, advanced, und das häckchen bei Log traffic setzen.
Neben grün gibt es noch andere Farben.

    Red: The packet was dropped.
    Yellow: The packet was rejected.
    Green: The packet was allowed.
    Gray: The action could not be determined.
Auszug aus der Online Hilfe

Und hier mal aus dem Firewall Log (echtzeit)

Drop

Deny

Gruß,
Peter

Dann wird deine Sophos entweder umgangen oder du nutzt nicht deren Firewall

Sehe ich auch so.
Da gibts irgendwo noch eine Backdoor Route, was natürlich fatal ist !!
Mach mal einen Traceroute (tracert) auf die Zieladresse und sehe dir die Hops an. Dort siehst du dann genau welchen Weg das Paket nimmt.

So, vielen vielen Dank an alle, jetzt funkt alles. Bei der Checkpoint war NAT enabled, bei Sophos musste eben auch noch das logging pro Rule angeschaltet werden. Und der Ping wurde geforwarded bei der Sophos. So ist das eben, wenn nichts dokumentiert ist und über Jahre jeder mal dran rum spielt. Ich habe das ganze jetzt erst einmal dokumentiert und werde nun die Management Netze in dem LAN alle in ein VLAN rücken.

Tracert ging sauber zur Checkpoint und dann zur Sophos. Nun ist bloß das blöde, dass ich den Client durch das Natting nicht direkt bei der Sophos in die Rolle eintragen kann. Vielleicht sollte ich bei den 3 Admins eine route auf dem lokalen Client zur Sophos anlegen. Mittelfristig werde ich die Checkpoint ablösen und hinter die Sophos einen CoreSwitch hängen und die VLANs neu erstellen. So zumindest der Plan.

So ist das eben, wenn nichts dokumentiert ist und über Jahre jeder mal dran rum spielt.

So sollte es aber eben NICHT sein !! Schon gar nicht an einer Firewall !! Da darf nur der Admin spielen und alle müssen "Bitte" sagen !

und werde nun die Management Netze in dem LAN alle in ein VLAN rücken.

Sehr vernünftig...!

Nun ist bloß das blöde, dass ich den Client durch das Natting nicht direkt bei der Sophos in die Rolle eintragen kann.

Deshalb trägst du auch die beteiligen lokalen VLAN Segmente aud dem NAT aus an der Checkpoint, so das die logischerweise Routing lokaler LANs NICHT NATet !
Das wäre ja auch Blödsinn und NAT dort lokal doch vollkommen überflüssig !
Behindert dich auch im Regelwerk an der Sophos.
Oder...du erlaubst an der Checkpoint ICMP Redirect (Typ 5) von Clients im 10.1.1.0er Netz (Beispiel). Dann schickt die CP einen ICMP Redirect an die Clients wenn diese zu Netzen an der Sophos wollen und leitet sie damit direkt auf das Sophos Gateway.
Damit ist die Checkpoint dann nicht mehr sinnloser Durchlauferhitzer für die lokalen Pakete an den Sophos VLANs. Mal ganz abgesehen vom Performanceverlust durch das vollkommen überflüssige NAT !
In einer pfSense FW ist das übrigens nur ein simpler Mausklick im Setup: