Beiträge von Mosconi

Ich hole das Thema mal wieder hoch, auch wenn es schon ein paar Monate alt ist.

Vaultwarden habe ich seit gestern am Laufen. Kaum hatte ich Port 80 und 443 offen, hat sich mein Email Postfach erstmal mit Meldungen gefüllt. Ist diese Menge an Anfragen normal? Hab erstmal die Schotten wieder dicht gemacht.

Ok, habs selber rausgefunden. Es war die lan local Regel Home-->Gateways

Shame on me... Du hast das schon richtig gelesen. Auf nem Mac habe ich noch nen IP Scanner drauf. Das ging damals vor 10 Jahren schneller als erst in die damalige Fritte sich einzuloggen und zu schauen, welcher Client welche IP hat.

Allerdings ist Nmap da schon umfangreicher.

Jetzt aber noch eine Frage an die Gelehrten....

Seitdem ich meine Firewallregeln etwas angepasst habe, musste ich heute feststellen, dass ich von meinem Laptop nicht mehr auf das USG komme. Weder per Browser 192.168.0.1, noch per ssh oder Ping. Hänge ich den Laptop aber direkt ins MGMT Lan, komme ich auf das USG. Also blockt wohl irgendeine Firewall Regel. Was ich mir aber nicht erklären kann ist, mit die erste Regel ist die, dass meine Admin Rechner auf alle Netze dürfen. Die IP meiner beiden (admin) Rechner ist per DHCP reservation vergeben. Dies hatte ich auch nochmal geprüft. Wieso kommen beide Rechner nicht auf das USG? Auf die anderen Geräte im MGMT LAN (Cloud Key, NAS) komme ich mit beiden Laptops. Ich blocke zwar danach noch alle Netze und Gateways gegeneinander, aber mit der Regel sollte es doch klappen?

Achso, ein Geheimnis mach ich da nicht draus. Mit

nmap -T4 - A -v -Pn (Client IP) habe ich nach erfolglosen Ping es versucht.

ICMP ist in der Firewall bei mir nur unter "Guest V4/6" erlaubt.

Heißt im Umkehrschluss wäre es damit in Lan local deaktiviert, oder?

Sodele, es scheint nun alles erstmal gut zu laufen. Firewall und Pi Hole funktionieren.

Der PiHole wollte nicht, da ich in der Firewall DNS Freigabe anstelle "UDP und TCP" Any drinstehen hatte. Warum es mit "Any" nicht funktioniert ist mir ein Rätsel.

Grüße und Danke an die Mannschaft für die Hilfe

So, bin wieder etwas weitergekommen. Der Neustart hat nun zumindest bewirkt, dass der Einblick in die anderen Subnetze nicht mehr so leicht möglich ist. Warum schreibe ich das: Wenn ich über nmap einen einfachen Portscan mache, findet nmap nichts. Mit einem anderen Scan sieht er doch noch, ob ein Client da ist oder nicht.

Sodele, nun hoffe ich mal, dass ich es richtig habe:

Funktionieren tut es aber noch nicht. Ich starte das USG mal neu. Evtl. klappt es ja danach....

Zitat

Zum Thema Lan Local nochmal...

Wenn du schon mit einem IP Scanner arbeitest, wird dir auffallen, dass die Gateway Adrerssen erreichbar sind... und das ist dass, was ich die ganze zeit versuche zu erklären! Dafür ist Lan Local zuständig.

Danke, das habe ich mittlerweile verstanden. Kannst du anhand des Screenshots erkennen, warum der IP Scanner hier aus dem IoT Netz in ein eigentlich geblocktes Netz schauen kann?

Hallo Razer,

erstmal vielen Dank für deine Hilfbereitschaft!

Bei mir hat sich die Uhr in der Zwischenzeit etwas weitergedreht. Das soll heißen, ich habe viele Regeln erstmal wieder gelöscht und bin gerade daran, alles Stück für Stück aufzubauen. Das versuche ich aber grad noch nach dem alten Wiki Firewall Beitrag.

Dazu habe ich eine Frage: Wenn ich die untere Regel anwende, ist mittels ping Befehl kein Client aus den anderen Subnetzen erreichbar. Das ist schon mal gut.

Wenn ich aber auf meinem MacBook den IP Scanner anwerfe, bekomme ich trotzdem die Clients aus den anderen Subnetzen angezeigt.

Jetzt weiß ich nicht genau, ob das so normal ist, oder ob da noch etwas nicht stimmt. Das MacBook hat in diesem Moment keine Berechtigung auf andere Subnetze zuzugreifen.

*

--------------------------------------------------------------------------------------------------------

Regel 3 „block all communication between VLANs“

SETTINGS>Routing & Firewall>FIREWALL>LAN IN>CREATE NEW RULE

Name>>>block all communication between VLANs

Action>>>Drop

Source Typ>>>Address/Port Group

IPv4 Address Group>>>all private IP-ranges RFC1918

Destination Type>>>Address/Port Group

IPv4 Adress Group>>>all private IP-ranges RFC1918

>>mit Save abspeichern<<

Wir haben mit Regel 3 die Kommunikation der Subnetze untereinander eingeschränkt. Geräte können sich über die Subnetz-Grenzen nicht sehen und auch nicht erreichen."

--------------------------------------------------------------------------------------------------------

Grüße aus dem Schwabenländle.

Hallo Zusammen,

ich habe mir gestern mal die Tapete "Firewall-Regeln 2.0 by Defcon" angesehen und dies versucht auf mein Netzwerk zu adaptieren.

Einerseits möchte ich dieses Regelwerk nicht betreiben, ohne grob zu verstehen, was welche Regel macht, andererseits gibt es mit dem Regelwerk bei mir Probleme, bei denen ich hoffe, von euch Hilfe zu erhalten.

1. Verständnisfrage

Bsp: block all communication between VLANs: Hier werden die IP-Ranges als Ziel verwendet.

Um zu verstehen, warum es hier richtig ist, die IP-Ranges zu nehmen wüsste ich gerne, was machen die IP-Ranges hier anders als die VLAN Gateway IP's?

2. Verständnisfrage

Was machen die "LAN local" Regeln anders als die "LAN in" Regeln?

Welcher Sichheitsvorteil geht dabei z.B.hervor?

Bevor ich nun zu den Problemen komme, vielleicht ein paar Fakten zu meinem Netzwerk:

192.168.0.1 # mein MGMT LAN

192.168.10.1 # mein DNS VLAN mit piHole

192.168.20.1 # mein Home VLAN

192.168.30.1 # (Kids Vorhalt)

192.168.40.1 # mein IoT VLAN

192.168.50.1 # (Kamera Vorhalt)

192.168.60.1 # mein Gast VLAN

1. Problem: admin device will nicht mit MGMT-LAN kommunizieren

Mein admin Rechner ist im Home Vlan beheimatet.

Dieser Rechner und noch ein weiterer sind im (admin devices)-Profil hinterlegt.

Beide haben eine fixed IP.

Will ich nun mit einem der beiden Rechner auf z.B. das MGMT LAN zugreifen (Bsp: 192.168.0.14) geht das nicht. Der Client aus dem MGMT LAN ist dann auch nicht anpingbar.

Pausiere ich die Regel 2013: "block communication between VLANs"

mit den lokalen IP-Ranges:

192.168.0.0/24

192.168.10.0/24

192.168.20.0/24

192.168.30.0/24

192.168.40.0/24

192.168.50.0/24

192.168.60.0/24

dann klappt auch der Zugriff auf das MGMT LAN problemlos. #Gottseidank gibt es die Pause-Funktion#

Hat jemand ne Idee, wie ich der Ursache auf den Grund gehen kann?

2. Problem: Mein Sorgenkind piHole

Dieser steckt im DNS VLAN.

Bei den Ports habe ich nur Port 53 eingetragen!

Trage ich die piHole-IP in ein VLAN ein, hat mein Rechner schlagartig keine Lust mehr, eine funktionierende Internetverbindung aufzubauen. Trage ich die PiHole IP aber NUR als WAN DNS Server ein, so klappt die Internetverbindung mit meinem Rechner. Doch genau das möchte ich ja nicht.

Woran kann es liegen, dass die piHole IP im VLAN überhaupt nicht funktionieren will?

Fehlen aus eurer Sicht noch andere wichtige Ports außer Port 53?

Wie könnte ich dem Problem auf die Schliche kommen?

Schonmal vorab vielen Dank für die Hilfestellung

Grüße Mosconi

So zurück zum eigentlichen Thema:

Nachdem nun wieder Pi Hole eingezogen ist, habe ich einen Test gemacht.

Trage ich die PI Hole DNS IP nur im WAN ein, so funktionieren alle Clients ohne Probleme.

Sobald ich aber die Pi Hole IP in den VLAN's eintrage kann mein Geschäftslaptop keine VPN Verbindung mehr herstellen und die Handys können keine Email mehr abrufen.

Ich habe keine Ahnung, warum dies so ist, aber ich denke, dass das kein Pi Hole Problem ist, sondern an meinen Unifi Einstellungen irgendwo liegt. Hat jemand ne Idee, wo das Problem liegen könnte?

Da das Wochenende eh beschissenes Wetter ergaben soll, bekomme ich wahrscheinlich die ein oder andere Minute Zeit.

Dann heißt es, SD Karte raus aus dem Pi und SSD ran. Dann gibts ne frische Install von Pihole.

Falls jemand ein paar gute Tipps hat, was man ggf. in welcher Reihenfolge einrichten sollte, wäre ich dankbar. Pihole mit Unbound ist ja erstmal schnell installiert. Und danach beginnt die Arbeit.

Ich hatte Adguard über längere Zeit genutzt und wollte mal PiHole ausprobieren. PiHole lief mit Unboud bzw. auch quad9 im Seitenaufbau langsamer als Adguard mit quad9. Auch muss ich erstmal verstehen, warum das Firmen VPN mit PiHole nicht läuft. In der query Liste hatte ich hier nichts gefunden. Ggf. wird das also woanders geblockt. PiHole wird schon nochmal ausprobiert. Hauptsache das VPN läuft. Grüße

Ne, da hast du recht. Vom PiHole bin ich auch erstmal wieder weg, weil mein Firmenlaptop nicht mehr übers VPN online ging etc....

Mir ging es zuletzt darum, dass mir alle Clients im Adguard aufgelistet werden und das mit der lokalen DNS -Namens Auflösung klappt.

Sorry, bin nur Maschinenbauer, daher muss man bei mir manchmal etwas weiter ausholen bzgl. der IT. Aber ich lerne dazu und bin für jede Hilfe mega dankbar!

Wenn ich das so richtig lese, dann muss ich diese Domains also auch in meinem seit heute installierten Adguard reinschrieben. Über den Punkt bin ich zumindest schonmal gestolpert.

Da werden von mir bestimmt noch 2-3 Fragen kommen, bis das in meinem Kopf ne logik ergibt. Aber Schritt für Schritt.

Danke

Folgende Frage dazu:

Ist hier letztendlich dann z.b. für das IoT VLAN die "192.168.40.1" einzutragen?

Zitat

Bei allen den DNS Cache gelöscht? Ansonsten mal abwarten bis die DHCP Lease abläuft

Wenn ich richtig liege, sollte das DHCP Lease doch nach 24h irgendwann mal ablaufen.

Der nslookup zeigt mir aber immer noch die falsche Domain.

Gibt es noch nen Punkt, wo ich was eintragen/machen sollte, damit das funktioniert?

Wäre halt toll, wenn mal ..... .iot.lan stehen würde, so wie im VLAN definiert.

nslookup 192.168.40.25 192.168.40.1
25.40.168.192.in-addr.arpa	name = ESP-4E347C.IoT.domain.de.

Zitat

Bei allen den DNS Cache gelöscht? Ansonsten mal abwarten bis die DHCP Lease abläuft

Ja, nachdem ich's ja anfangs nicht wusste, hab ich gedacht, mach ich's gleich richtig.

Zitat

Was sagt denn irgend ne Windows Kiste wenn du nslookup ausführst?

Sodele:

Raspi mit Debian liefert: *.IoT.domain.de.

Windows liefert: *.IoT.domain

Ubuntu liefert: *.IoT.

Wenn's Not tut, hat ich noch nen Mac, von dem ich aus das testen könnte.

Da blick ich nicht mehr durch.

Windows habe ich nicht direkt zur Hand. Den Pi hatte ich neu gestartet. Aber das hatte leider auch nichts gebracht.

Windows fahre ich später mal hoch und versuche es dort.

Sodele, hab erstmal das USG neugestartet und nachdem es danach noch nicht funktioniert hatte mittels clear dns forwarding cache

den Cache geleert. Leider noch ohne Erfolg.

Hast du noch ne Idee, woran es liegen kann?