[Gelöst] SG300 10 Port Inter VLAN Routing kein Internet Zugriff an UTM

[Cloud Runner]

Folgendes möchte ich realisieren:

UTM an Port 10 im VLAN 10 im eigenen VLAN
Clients an Ports 1-4 im VLAN 20
Clients an Ports 5-8 im VLAN 30

VLAN 20 und 30 sollen über VLAN 10 ins Internet jedoch nicht untereinander kommunizieren, ACLs habe ich noch nicht erstellt da ich auch so kein Inet Zugang habe. (Evenuell ist das der Fehler?)
Laut den diversen Tutorials sind ACLs erstmal nicht nötig um ins Internet zu kommen sondern lediglich um die Kommunikation zwischen VLAN 20 und 30 zu verhindern.

Der SG300 befindet sich bereits im L3 Modus.

Ping und traceroute vom Switch aus den jeweiligen VLANs an die UTM funktionieren.
Ping und tracerroute von den clients zu den jeweiligen VLAN Interfaces funktioniert auch.

Die clients erhalten als Default Gateway jeweils die IP des VLAN Interfaces, eine IP aus dem jeweiligen Pool und als DNS die IP der UTM.

Setze ich die clients ins VLAN 10 dann hab ich natürlich sofort Inet Zugang.


SG300 config:

Alle Ports sind auf access gesetzt.

VLAN Port Membership:

Port 1-4 VLAN 20 untagged
Port 5-8 VLAN 30 untagged
Port 10 VLAN 10 untagged (eventuell steckt hier der Fehler und der Port muss auf trunk/allgemein und Mitglied aller VLANs sein?)

VLAN Interfaces

VLAN 10: 192.168.10.254
VLAN 20: 192.168.20.254
VLAN 30: 192.168.30.254

DHCP Pools:
VLAN 10 wird von der UTM übernommen
VLAN 20 auf dem SG300 mit dem Gateway 192.168.20.254 / DNS IP der UTM
VLAN 30 auf dem SG300 mit dem Gateway 192.168.30.254 / DNS IP der UTM

Ipv4 Route:
Default route: 0.0.0.0 0.0.0.0 UTM IP

UTM Config

Routen:
192.168.10.0 ->Gateway 192.168.10.254
192.168.20.0 ->Gateway 192.168.10.254
192.168.30.0 -> Gateway 192.168.10.254

 

[Eye-Q]

Da Du auf dem Switch von einem VLAN in ein anderes routen willst, wären ACLs in deinem Aufbau auf jeden Fall notwendig. Ich würde da aber nicht den Aufwand treiben, einem Switch das Routen beizubringen, sofern die UTM (UTM ist ein allgemeiner Name - was für ein Hersteller ist das?) auch VLANs kann, was sie können müsste.

Somit würde ich das folgendermaßen aufbauen:

• UTM eth0 VLAN 1 (bzw. ohne VLAN): interne IP-Adresse: 192.168.10.254 mit DHCP-Server (damit Du dich notfalls mit einem Notebook an eth0 anstecken und die UTM konfigurieren kannst, falls Du irgendwas in den VLANs kaputt gemacht hast)
• UTM eth0 VLAN 20 interne IP-Adresse: 192.168.20.254 mit DHCP-Server
• UTM eth0 VLAN 30 interne IP-Adresse: 192.168.30.254 mit DHCP-Server
• Switch Port 1-4 VLAN 20 untagged
• Switch Port 5-8 VLAN 30 untagged
• Switch Port 10 VLAN 20+30 tagged
• UTM eth0 mit Switch Port 10 verbinden
• Auf der UTM eine Firewall-Regel für den Zugriff von VLAN 20 in Richtung Internet und eine Regel für den Zugriff von VLAN 30 in Richtung Internet einrichten

Da eine UTM standardmäßig jeglichen Verkehr zwischen Interfaces unterbinden sollte und auf der UTM ein VLAN ein Interface ist, können die VLANs somit nicht untereinander kommunizieren, aber mit dem Internet, fertig ist die Laube.

 

[hominidae]

• Auf der UTM eine Firewall-Regel für den Zugriff von VLAN 20 in Richtung Internet und eine Regel für den Zugriff von VLAN 30 in Richtung Internet einrichten

Da eine UTM standardmäßig jeglichen Verkehr zwischen Interfaces unterbinden sollte und auf der UTM ein VLAN ein Interface ist, können die VLANs somit nicht untereinander kommunizieren, aber mit dem Internet, fertig ist die Laube.

...oder eben, falls in der Firewall das forward-ing von lokalen Netzen grundsätzlich erlaubt ist, aus Richtung VL20 und VL30 alles drop-en, was nicht Richtung WAN geht.

 

[Cloud Runner]

Danke für die Antworten.
Mit UTM ist die Sophos 9 UTM Home Edtion gemeint.

D.h. ich kann den SG300 wieder in den L2 Modus versetzen und das VLAN Routing etc. mache ich dann über die Sophos.

 

[Seratio]

Genau das.

Es gibt noch die Möglichkeit das über so genannte Private VLANs zu lösen. Du hättest dann mehrere VLANs welche sich ein Netz teilen, aber sich untereinander nicht erreichen können.
In diesem Fall würdest du dem Port zur Firewall ein Primary VLAN 10 geben und den Port 1-4 das Community VLAN 20 und dem Port 5-8 das Community VLAN 30.

Community VLANs können sich nicht direkt untereinander unterhalten. Sie können aber problemlos zum dazugehörigen Primary VLAN Daten schieben.

 

[Eye-Q]

Mit UTM ist die Sophos 9 UTM Home Edtion gemeint.

Ja, die kann auf jeden Fall VLANs, also einfach so aufbauen wie ich es vorgeschlagen habe.

D.h. ich kann den SG300 wieder in den L2 Modus versetzen und das VLAN Routing etc. mache ich dann über die Sophos.

Richtig, ein Inter-VLAN-Routing auf dem Switch ist ja nicht notwendig, da zwischen den VLANs ja keine Kommunikation möglich sein soll.

Anders wäre es, wenn Kommunikation möglich sein soll, dann könnte ein Inter-VLAN-Routing über die wahrscheinlich nur über 1 Gbit/s angebundene UTM ein Flaschenhals entstehen, je nachdem wie viele Daten zwischen den VLANs übertragen werden sollen.

 

[underclocker2k4]

Inter.VLAN-Routing auf dem Switch macht dann Sinn, wenn man Verkehr an der Firewall vorbei haben will, weil man z.B. viel Bandbreite braucht oder wenn die L3-Trennung nicht vom Sicherheitsanspruch her kommt.
ACLs sind aktuell keine wirklich gut geeignete Möglichkeit mehr, den Traffic zu leiten. ACL beziehen sich ja nur auf die IP.
Aber man will ja (eigentlich) mindestens auf L4 Reglementierung. Sprich man z.B. erreichen, dass der Stöpsel im Kinderzimmer zwar auf das Webinterface der Raspiwetterstation kommt, aber nicht auf das Terminal. z.B..
Firewalls können auch noch viel weiter überwachen und unterbinden. (kostet dann aber entsprechend)

Wenn also der Durchsatz so passt, dann auf jeden Fall alles per VLAN über den Trunk auf die Firewall ziehen und die dann ihre Aufgabe machen lassen.

 

[Cloud Runner]

Nochmals vielen Dank, insbesondere an Eye-Q.
Funktioniert alles so wunderbar.

Mir ging es primär darum mein Ryzen 9 3900 der demnächst für XMR schwitzen darf aus dem restlichem Netzwerk rauszuhalten.

 

[underclocker2k4]

Was soll das bezüglich XMR (Crypto?!) bringen?

 

[Cloud Runner]

Na der kann dann dort alleine rumdümpeln und hat kein Zugriff auf meine anderen clients(und umgekehrt). Vertrauen ist gut Kontrolle ist besser.
Mir sind schon mal 2012 meine Namecoins durch kompromittierte mining software abhanden gekommen.

 

[underclocker2k4]

Das ist natürlich Kacka. Dann solltest du den aber auch outbound entsprechend zusammenstauchen.

 

[Cloud Runner]

Du meinst den ausgehenden traffic? Der bekommt nicht mehr als DNS und den Port zum Pool, kurzfristig natürlich normalen Web Zugang damit ich nicht Treiber & co per USB Stick hin und her schubsen muss.