Beiträge von Oellewa

Hallo zusammen,

wer kann mir denn einmal folgende Regel genau erklären.

allow established/related sessions Quelle: any and Ziel: any Zustand: Hergestellt und Zugehörig.

Hintergrund ist folgender. Ich habe einen Pi-Hole und der funktioniert auch Prima. Ich möchte jetzt aber ein VLAN nicht zum Pi-Hole lassen sondern nur ein bestimmten Client daraus.

Pi-Hole --> VLAN 10

Clients --> VLAN 20

Regeln:

1. allow established/related sessions --> Quelle: any --> Ziel: any
2. allow Client from VLAN 20 to DNS --> Quelle: Client IP --> Ziel: Port 53
3. block DNS from VLAN 20 to DNS --> Quelle:VLAN 20 --> Ziel: Port 53

So wie die Regeln jetzt stehen landen trotzdem die anderen Clients aus VLAN 20 am Pi-Hole.

Wenn ich die Block Regel aber vor die "established" Regel setze kommt nichts mehr beim Pi-Hole an.

1. allow Client from VLAN 20 to DNS --> Quelle: Client IP --> Ziel: Port 53
2. block DNS from VLAN 20 to DNS --> Quelle:VLAN 20 --> Ziel: Port 53
3. allow established/related sessions --> Quelle: any --> Ziel: any

Was ist der genaue Grund dafür? Deswegen würde ich die "established" Regel gerne genau verstehen.

Beispiele sind immer am besten.

Vielen Dank

Zitat von Tuxtom007

Rausgehend ( WAN out ) kann gut alles offen sein, ich ungefährlicher, aber WAN In, also alles was vom Internet auf deiner WAN-Schnittstelle reinkommt, sollte per Default geblockt sein.

Grundregel Firewall: Erst mal alles blocken und dann nur das freischalten, was wirklich benötigt wird.

Aber da ist ja mein Problem. Welche Regel wende ich denn an, die ich vor die Block Regel "any" to "any" setze, um überhaupt surfen zu können.

Zitat von razor

Da ja von außen nix unerwartetes reinkommt brauchst Du Dich darum nicht zu kümmern.

Du könntest nur verhindern, dass irgendetwas raus geht. Das würde ich dann aber über das entsprechende VLAN (z.B. IoT) trennen. Da konfigurierst Du dann alles "weg", was nicht nach draußen gehen soll.

Ja dies habe ich so realisiert. Ich habe mehrere VLAN's. Eines hat keinen Zugriff zum Internet. Doch mein Grundproblem sind immer wieder Angriffe die durch die Firewall geblockt werden. Und ich nicht ganz verstehe wie eine bestimmte IP im Internen Netzwerk angegriffen werden kann. Diese IP muss ja nach außen irgendwelche Ports geöffnet haben und sichtbar sein. Daher würde ich gerne alles mögliche was raus geht sperren und natürlich was rein geht.

Zitat von Tuxtom007

WAN IN (WAN eingehend)

Alles was vom Internet auf die WAN-Schnittstelle des Security Gateway kommt, ist WAN IN. Es kommt also Datenverkehr aus dem Internet zum Security Gateway. Ein Blick in die Regeln zeigt auch eventuelle Portweiterleitungen. Diese werden absichtlich und gewollt vom Internet in das private Netzwerk dahinter gelassen. Die Firewall prüft also, was kommt vom Internet auf das USG (die Firewall) und was soll damit passieren.

WAN OUT (WAN ausgehend)

Der Datenverkehr vom privaten Netzwerk ins Internet ist hier gemeint. Möchte ich zum Beispiel für alle Netzwerke dahinter den Port 22 für SSH blockieren, ist hier der richtige Ort. Allerdings heißt das auch, für wirklich alle Netzwerke dahinter.

(Quelle weiss ich nicht mehr )

Die habe ich auch schon öfters gelesen, jedoch verstehe ich das nicht. Es scheint ja alles offen zu sein sonst könnte ich doch nicht surfen. Wenn ich jetzt meine Block Regel "any" zu "any" setze geht ja nichts mehr.

Zitat von razor

Hast Du Dich schon in unserem wiki umgesehen? Da gibt es einen sehr ausführlichen Artikel:

Firewall-Regeln by EJ

Um auf Deine Frage einzugehen bzgl. der Sinnhaftigkeit: ich würde mir VLANs erstellen und darauf dann die Regeln anwenden, aber nicht auf WAN in oder WAN out. Im ersten LAN (ohne VLAN-ID) sollten sich keine Hosts aufhalten und auch sollte der IP-Adressraum nicht geändert weren. #BestPractises

Genau wie in dem Beitrag beschrieben habe ich meine VLAN's und Firewall Regeln auch angelegt. Aber wieso blocke ich nicht vorher schon unerwünschten Traffic?

Hallo Community,

wer von den Experten kann mir denn mal die WAN in und WAN out Firewall Regeln erklären. Ich verstehe dies einfach nicht.

Würde gerne alles was eintrifft blockieren. Habe eine Blockregel mit Quelle "any" und Ziel "any". Dann komme ich natürlich nicht ins Internet.

Habe davor eine allow Regel --> Quelle: Port 443 und 80 Ziel: "any" und danach habe ich einmal Quelle: "any" und Ziel: Port 443 und 80 erstellt. Bei beiden Regeln komme ich nicht ins Internet.

Will dann nach und nach die Ports freigeben die meine Geräte brauchen. Oder ist es generell Sinnfrei solche Regel zu erstellen?

Da ich es aber gerade überhaupt nicht verstehe kann ich die Sinnfrage nicht klären.

Über Antworten und vielleicht ein paar Beispiele dazu würde ich mich freuen.

VG

Guten Morgen Community.

Vielen Dank für die Antworten.

Den Link von "swerner" hatte ich in meiner Beschreibung auch mit angegeben und berichtet dass ich es damit nicht hinbekommen haben.

Habe jetzt die neuste Beta Firmware "1.11.0-20" von Unifi-OS eingespielt und es dann nochmals versucht. Und siehe da es klapp sehr gut.

Ob es wirklich daran lag kann ich nicht sagen.

Der mDNS Traffic findet nur noch zwischen VLAN 20 und VLAN30 statt. Dies mit ausgeschaltetem mDNS Dienst von Unifi.

Vielen Dank an alle.

Hallo Ede,

vielen Dank für die schnelle Antwort.

Ich bin kein Experte auf dem Gebiet.

Meinst du mit der Config Datei die config.gateway.json Datei? Diese soll bei der UDM Pro nicht funktionieren. Hast du die auf einer UDM Pro laufen?

VG Oellewa

Hallo Communitiy

Ich brauche mal Hilfe von einigen Experten unter euch. Ich habe folgendes Unfi Setup.

• 1 x UDM Pro
• 1 x US-16-150W-E
• 3 x AP-AC-PRO
• 3 x USW-Flex-Mini

Netwerk Konfiguration:

• VLAN 01 —> 192.168.10.1 —> Management (Unifi Geräte)
• VLAN 20 —> 192.168.20.1 —> BASIC (Alle Geräte mit Internetzugang)
• VLAN 30 —> 192.168.30.1 —> HOME (smart Home Geräte ohne Internet)
• VLAN 40 —> 192.168.40.1 —> GAST (Gästenetzwerk mit Gastrichtlinien)
• 192.168.50.1 —> VPN (VPN Netzwerk)

Firmware:

• Unifi Controller: 6.4.54
• Unifi-OS 1.10.4

Ausgangssituation und Problemstellung:

In meinem VLAN 30 die befindet sich Homekit-Zentrale und in meinem VLAN 20 ist mein iPhone mit der Home App. Die Firewall Regeln habe ich so angepasst das kein Datenverkehr zwischen den VLANs stattfindet.

Einzelne Geräte wie mein MacBook und iPhone dürfen von VLAN 20 auf das VLAN 30 zugreifen. Alles funktioniert wie es soll.

Zu Anfang funktionierte die Steuerung der Homekit Komponenten nicht, da das iPhone die Homekit-Zentrale nicht gefunden hat.

Dann habe ich unter den Einstellungen -> Dienste -> MDNS —> „Multicast DNS aktivieren“ eingeschaltet. Danach war eine Steuerung möglich und alles funktioniert wie es soll.

In einigen Foren habe ich aber gelesen dass der mDNS Traffic über die VLANs hinweg und sogar über den WAN Ausgang verteilt wird. Dies habe ich mit einem Laptop und dem Programm „Wireshark“ getestet. Der MDNS Traffic landet jetzt auch in meinem VLAN 10 (Unifi Geräte) und dem VLAN 40 (Gäste).

Dies ist meiner Meinung nach ja nicht Sinn der Sache.

Dann habe ich was über den mDNS Repeater gelesen, was von der UDM-Pro aber nicht unterstützt wird und nur per Jason Datei auf der USG funktionieren soll.

Nach weiterer suche bin ich auf den folgenden Artikel gestoßen: https://www.brandonmartinez.co…-mdns-with-apple-homekit/

Dort wird ein angepasster mDNS Reflector installiert der nur zwischen ausgewählten VLANs hinweg den Traffic verteilen soll.

Dies habe ich auch getestet und leider keinen Erfolg damit gehabt. Der Artikel stammt aus September 2020 und ist vielleicht mit der aktuellen Unifi Firmware nicht möglich.

Jetzt habe ich überlegt diese Verteilung des mDNS Traffic mit Firewall Regeln zu unterbinden, doch da stoße ich meine Grenzen. Ich habe folgende Block Regeln erstellt.

Quelle: VLAN HOME Ziel: IPv4 Adressgruppe mit der IP 224.0.0.251

Quelle: VLAN BASIC Ziel: IPv4 Adressgruppe mit der IP 224.0.0.251

Dies unterbindet den mDNS Traffic in das VLAN 10 und VLAN 40.

Mit Wireshark getestet.

Jetzt kann ich die Geräte nur nicht mehr mit dem iPhone steuern. Und bei den Freigabe-Regeln scheitere ich gerade.

Bin offen für konstruktive Anregungen und auch Kritik.