Firewall: Isolated Network und explizite Allow-Regeln funktioniert nur zu 50% - warum?

Moin,

wie ich unter

Thread

Management LAN nachträglich freischaufeln

Moin,

ich hab aus Anfangszeiten alle UniFi Geräte (Clients) und lokale Geräte (Devices) in das VLAN 1 gelegt. Dabei sind die IP-Adressen der Clients mit statischen IPs belegt (192.168.30.20-.30), während die Devices IPs via DHCP bekommen, einige davon aber mit „festen“ IPs.

Das möchte ich nun trennen, d.h. ein neues VLAN anlegen und die Devices dorthin verschieben. Anschließend (sorry, Sternzeichen Waage) soll das Management-LAN die IP Range 192.168.10.0/24 bekommen.

Frage(n):

- was passiert,…

maxim.webster

August 22, 2025 at 8:22 PM

schrieb, habe ich jüngst erfolgreich meine Netzwerke aufgeteilt. Für diesen Thread relevant sind folgende Infos:

• Netz "HOME", Zone "internal", dort befindet sich ein Netzwerk-Drucker mit IP 192.168.20.5
• Netz "DMZ", Zone "dmz" dort befindet sich ein http-Service mit IP 192.168.40.100
• Netz "Work", Zone "internal" ist ein isolated network, dort befindet sich ein Client-PC mit IP 192.168.30.245

Der http-Service im Netz "DMZ" ist via Port-Freigabe aus dem Internet über eine Public Domain erreichbar (service.example.com). Damit der Service auch von innen unter der URL erreichbar ist, gibt es einen Custom DNS Eintrag, der service.example.com mit der IP 192.168.40.100 beantwortet.

Soweit das Setup, jetzt zur Frage:

Die WORK-Rechner sollen sowohl den Drucker, als auch den http-Service erreichen dürfen. Darum habe ich ein IP-Group Profile angelegt, welches diese beiden IPs beinhaltet:

Außerdem habe ich eine Firewall-Regel angelegt, welche Rechnern aus dem WORK-Netz via IP-Group den Zugriff auf diese beiden IPs gewähren soll:

So, jetzt das nicht Nachvollziehbare:

1. Zugriff auf den Drucker ist möglich. Ein "tracert" (es sind Windows Clients) zeigt den Weg über die UDM Pro zum Drücker (2 Hops)
2. Zugriff auf den http-Service ist nicht möglich, "tracert" kommt bis zur UDM Pro, dann Timeouts

Wo muss ich suchen?

Update: Die Ursache für dieses Verhalten ist offenbar der "Isolate Network" Schalter im WORK-Netzwerk. Wird er deaktiviert, kann auch der http-Service erreicht werden - aber natürlich auch jeder andere Service aus dem HOME und DMZ-Netz.

Nochmal nachgedacht, sind die Zonen-Übergange zwischen WORK und HOME internal zu internal, der Übergang WORK zu DMZ ist aber internal zu dmz. Allerdings darf (lt. Standard-Regelwerk) die Zone DMZ Traffic "returnen", d.h. wenn aus WORK eine Anfrage in DMZ geht, dann sollte auch eine Antwort möglich sein.

Also: Wie bekomme ich es hin, dass WORK isoliert bleibt, bis auf die spezifizierten Ausnahmen?

Quote from AGro-99

Ohne das jetzt geprüft zu haben, meine ich, dass die Einstellung ‚Isolate Network‘ bei ‚Work‘ zu ZBF-Regeln führt, die eine Kommunikation von Geräten aus ‚Work‘ zu anderen Zonen unterbinden, nicht aber zu anderen Netzwerken innerhalb der Zone in der sich ‚Work‘ befindet. Der Datenverkehr zu Geräten in ‚Home‘ wird daher von dieser Einstellung nicht berührt.

Also, der Haken bei "Isolate Network" führt zu mehreren Einträgen in der Firewall, die auch gruppiert dargestellt werden:

Die 192.168.30.0/24 ist dabei das isolierte Netzwerk WORK, welches entsprechend weder in seine eigene Zone (internal), noch in die anderen Zonen Hotspot und DMZ kommunizieren darf.

Nur - die explizite Erlaubnis steht ganz oben in der Firewall-Regel und sollte entsprechend vor den Isolated Networks greifen.

Und während ich das kopiere, wird mir auch klar warum es nicht funktioniert: Die Regel regelt die Kommunikation von internal zu internal. 192.168.40.100 ist aber in DMZ. Das passt einfach nicht zusammen, ich brauche eine zweite Regel.

Danke für den Gedankenanstoß. Thema erledigt.