Firewall Regeln VLAN, IoT, adminLAN?

[lalala987]

Liebe Leute

Ich möchte mir mit PFSense als Router und einem Unify Switch ein Heimnetz bauen.
Am Switch hängen die Clients wie WLAN Access Points, Smart Home Zeugs, PCs.
Die verschiedenen Geräte möchte ich in VLANs (IoT, admin, Gast, etc) unterteilen und ganz klassisch mit Firewall Regeln voneinander trennen.

Was mir unklar ist:
Ist es möglich zu verhindern dass das IoT VLAN mit meinem admin-VLAN kommuniziert, jedoch die Clients aus dem admin-VLAN das IoT-VLAN sehr wohl aufrufen können?

Beispiel:
Ich habe ein Gerät im VLAN "IoT" (1) und meinen Admin PC im VLAN "admin" (2)

Wie müsste ich die FW Regeln konfigurieren, sodass ich von 2 auf 1 zugreifen kann, jedoch ein öffnen von Verbindungen von 1 auf 2 untersagt ist, JEDOCH erlaubt ist wenn zuvor 2 die Verbindung initiert hat?

Genügt es mit einer einfachen Block/Discard Regel auf PFSense von 1 nach 2 zu arbeiten? Kann ich dann von 2 nach 1 Verbindungen aufbauen und "sehe" alles?

Grüße!

 

[up.whatever]

Stichwort: Stateful Packet Inspection

 

[martinallnet]

Mit einer Regel die Richtung admin nach established und related filtert.

 

[Raijin]

Vorweg: IoT-Geräte sind leider in vielen Fällen nicht wirklich für komplexe (V)LAN-Setups geeignet. Viele Apps dieser Geräte arbeiten mit Broadcasts, sie suchen also aktiv im gesamten lokalen Netzwerk - in dem Falle dann nur innerhalb des VLANs - nach Geräten, die verbunden werden können. Packt man alles an IoT in ein separates VLAN, stehen die Chancen daher gut, dass sich das eine oder andere IoT-Gerät nicht vom Smartphone im WLAN des Haupt-VLANs steuern lässt. Dies gilt es also zuvor zu prüfen, um böse Überraschungen zu vermeiden.

Was die Firewall angeht: Prinzipiell kann man das wie eine DMZ behandeln. Eine DMZ ist von der Firewall her für NEW Verbindungen nur einseitig durchlässig, vom Hauptnetz in die DMZ. Aus Richtung der DMZ ins Hauptnetz wird hingegen nur ESTABLISHED/RELATED erlaubt. Das schließt die Antwort-Pakete mit ein und ebenso "verwandte" Verbindungen, sowas wie die Control- und Data-Verbindungen im FTP-Protokoll.

Haupt ---NEW---> DMZ (IoT)
Haupt <---ESTABLISHED/RELATED--- DMZ (IoT)
Haupt <|||--NEW--||| DMZ (IoT)

Aber wie gesagt, behalte im Hinterkopf, dass ein zugenageltes IoT-(V)LAN Probleme verursachen kann, leider. Nicht alle Hersteller haben solche Szenarien bedacht und eine manuelle Verbindung anhand der IP in die App eingebaut wie Philips es beispielsweise bei der Hue-App getan hat.

 

[lalala987]

aahh! das scheint also genau das zu sein, wonach ich gesucht habe! ich versuch das mal nachzubauen.
bin leider anfänger und momentan nur in einer virtuellen testumgebung unterwegs...

 

[Raijin]

Dann rate ich zum KISS-Prinzip. Du hast oben schon mindestens 4 VLANs angedeutet, IoT, Admin, Gast, "etc". Weniger ist manchmal mehr, wenn man sich nicht so sehr auskennt. Ich würde an deiner Stelle erstmal mit mit Haupt- und Gastnetzwerk anfangen. Wenn du das Prinzip der Firewall verstanden hast und sie selbsttätig konfigurieren kannst, fügst du eben noch ein 3. VLAN hinzu und schaust weiter. Baust du jetzt aus dem Stegreif ohne nennenswerte Kenntnisse aber gleich 4 oder mehr VLANs, garantiere ich dir, dass du bald keinen Frisör mehr brauchst, weil du dir die Haare bis zur Glatze raufst

 

[lalala987]

hahah, genau meine gedanken! derzeit habe ich bloß 2 VLANs vorgesehen. admin und IOT.
später dann kameras etc.

 

[Raijin]

Du musst dir letztendlich vor Augen führen was du damit erreichen willst. Wenn zwischen zwei VLANs beispielsweise keinerlei Regeln existieren, sie also beidseitig vollumfänglich zugreifbar sind, stellt sich die Frage inwiefern eine Trennung in (V)LANs überhaupt sinnvoll ist. Man nutzt VLANs nicht zum "hübschen Sortieren" von Geräten, sondern um separate Netzwerke mit unterschiedlichen Berechtigungen über ein und dieselbe Infrastruktur zu verteilen und/oder Broadcast-Domänen aufzusplitten. Dabei müssen die jeweiligen Endgeräte aber auch mitspielen, wie ich eingangs schon angedeutet habe.


Eine kleine Anekdote aus dem Arbeitsleben:

Ich habe vor ein paar Jahren an einer Anlage bei einem Kunden ein System mit Laser-Distanzsensoren zur Qualitätsüberwachung mitentwickelt. Es waren über eine Arbeitsbreite von knapp 3 Metern insgesamt 10 Sensoren. Jeder dieser Sensoren wurde über das Netzwerk angesteuert. Als ich Probleme bekam, die Sensoren über die VPN-Verbindung unserer Fernwartung anzusteuern, klickte ich mich nochmal durch deren Menü und wollte prüfen ob ich beim Standard-Gateway keinen Vertipper hatte. Und was musste ich feststellen? Man konnte IP + Subnetzmaske konfigurieren, aber ein Standard-Gateway war nicht vorgesehen.
Der Support vom Hersteller - Leuze - zeigte sich überrascht und fragte mich wozu ich das denn bräuchte, sollen die Sensoren doch "gar nicht ins Internet". Fernwartung via VPN (ohne NAT) war denen gar nicht in den Sinn gekommen. Ein paar Tage später bekam ich eine neue Firmware, dieses Mal mit Standard-Gateway.

Schlägt man nun den Bogen zu IoT-Geräten, insbesondere Billig-Kram, kann man sich vorstellen, dass die dort erst recht nicht an erweiterte Szenarien denken, die über das "alles in einem Netzwerk"-Szenario hinausgehen. Nicht selten fehlt dort schlicht und ergreifend das KnowHow und der smarte Teil wird lediglich dazugekauft, möglichst bil... .. günstig natürlich.