14
Lokale Subnetze für VLANs unterbinden
Hallo zusammen,
die letzten Tage hatte ich vor mein Netzwerk über die pfSense weiter abzusichern, indem ich die "Gäste" gegenüber den anderen Subnetzen sperre, bin dabei aber über das Ziel hinaus geschossen und musste die Regel erstmal deaktivieren, da nun auch kein Internet mehr ging.
Zur Firewall:
192.168.1.0/24 Standard privates Subnet
192.168.10.0/24 Freundenetzwerk
192.168.20.0/24 Gastnetzwerk
192.168.30.0/24 Freundenetzwerk erweitert
192.168.40.0/24 IoT
192.168.100.1 vorgelagerter Speedportmüll (geht leider aktuell nicht anders durch Hybrid)
Das private Netzwerk darf überall hin und die anderen Subnetze sollen gegeneinder und zum Heimnetz abgeschottet sein.
Bisher hatte ich dort beispielsweise ganz oben in den Regeln jeweils beispielshaft "Deny; Source VLAN 10 net; Destination VLAN 30 net; Port any; Protocol any
Das als Beispiel und jeweils in den Subnetzen 4 Regeln. 192.168.10.0 war damit auf 1.0, 20.0, 30.0, 40.0 gesperrt. Die anderen Subnetze analog dazu.
Im lokalen Netz hatte ich die Router Netzwerke verboten indem 100.0/24 verboten habe, dies davor jedoch für 2 Admin Clients erlaubt habe.
Nun ist mir mal aufgefallen, bzw hätte es auch klar sein müssen, dass aus den anderen ich nenne sie mal Gästenetzwerken immer die GUI des vorgelagerten Routers sichtbar ist.
Bei mir eigentlich weniger interessant, da die weniger Nutzer mit Sicherheit nicht Subnetübergreifend scannen würden, wenn überhaupt.
Mir geht es da aber um die Sache an sich und dem Lerneffekt.
Also war mein letzter gescheiterter Versuch, dass ich die Einzelregeln gegeneinander entfernt habe.
Stattdesse habe ich ein Alias erstellt indem ich die privaten Subnetze definiert habe 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Dann um beim Beispiel Vlan 10 zu bleiben: Deny, Source VLAN 10 net; Destination (Alias Subnets), any, any
Das Ende vom Lied war es gab auch kein Internet mehr.
Ziel war ja die Subnetze gegeneinander abzuschotten und mögliche Erweiterungen nicht jeweils einzeln editieren zu müssen, sondern jeweils schon abgeschaltet zu haben.
Hätte da jetzt vor der Regel jeweils eine Pass Regel zu der pfsense selbst stehen müssen, da ich mir so auch den Zugriff zur pfSense als Router verwehre?
die letzten Tage hatte ich vor mein Netzwerk über die pfSense weiter abzusichern, indem ich die "Gäste" gegenüber den anderen Subnetzen sperre, bin dabei aber über das Ziel hinaus geschossen und musste die Regel erstmal deaktivieren, da nun auch kein Internet mehr ging.
Zur Firewall:
192.168.1.0/24 Standard privates Subnet
192.168.10.0/24 Freundenetzwerk
192.168.20.0/24 Gastnetzwerk
192.168.30.0/24 Freundenetzwerk erweitert
192.168.40.0/24 IoT
192.168.100.1 vorgelagerter Speedportmüll (geht leider aktuell nicht anders durch Hybrid)
Das private Netzwerk darf überall hin und die anderen Subnetze sollen gegeneinder und zum Heimnetz abgeschottet sein.
Bisher hatte ich dort beispielsweise ganz oben in den Regeln jeweils beispielshaft "Deny; Source VLAN 10 net; Destination VLAN 30 net; Port any; Protocol any
Das als Beispiel und jeweils in den Subnetzen 4 Regeln. 192.168.10.0 war damit auf 1.0, 20.0, 30.0, 40.0 gesperrt. Die anderen Subnetze analog dazu.
Im lokalen Netz hatte ich die Router Netzwerke verboten indem 100.0/24 verboten habe, dies davor jedoch für 2 Admin Clients erlaubt habe.
Nun ist mir mal aufgefallen, bzw hätte es auch klar sein müssen, dass aus den anderen ich nenne sie mal Gästenetzwerken immer die GUI des vorgelagerten Routers sichtbar ist.
Bei mir eigentlich weniger interessant, da die weniger Nutzer mit Sicherheit nicht Subnetübergreifend scannen würden, wenn überhaupt.
Mir geht es da aber um die Sache an sich und dem Lerneffekt.
Also war mein letzter gescheiterter Versuch, dass ich die Einzelregeln gegeneinander entfernt habe.
Stattdesse habe ich ein Alias erstellt indem ich die privaten Subnetze definiert habe 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Dann um beim Beispiel Vlan 10 zu bleiben: Deny, Source VLAN 10 net; Destination (Alias Subnets), any, any
Das Ende vom Lied war es gab auch kein Internet mehr.
Ziel war ja die Subnetze gegeneinander abzuschotten und mögliche Erweiterungen nicht jeweils einzeln editieren zu müssen, sondern jeweils schon abgeschaltet zu haben.
Hätte da jetzt vor der Regel jeweils eine Pass Regel zu der pfsense selbst stehen müssen, da ich mir so auch den Zugriff zur pfSense als Router verwehre?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665697
Url: https://administrator.de/contentid/665697
Ausgedruckt am: 21.11.2024 um 18:11 Uhr
14 Kommentare
Neuester Kommentar
Moin,
du kannst einen Alias für dir RFC1918er Netze anlegen und diese Blocken. Dann geht das nicht mehr.
Gruß
Spirit
du kannst einen Alias für dir RFC1918er Netze anlegen und diese Blocken. Dann geht das nicht mehr.
Gruß
Spirit
Zitat von @fnbalu:
Stattdesse habe ich ein Alias erstellt indem ich die privaten Subnetze definiert habe 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Stattdesse habe ich ein Alias erstellt indem ich die privaten Subnetze definiert habe 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Hätte da jetzt vor der Regel jeweils eine Pass Regel zu der pfsense selbst stehen müssen, da ich mir so auch den Zugriff zur pfSense als Router verwehre?
Wie du schon selbst vermutest, bewirkt das Deny auf die RFC1918 Adressen das Aussperren. Dein Speedport kommt ja auch aus dem Bereich, ebenso die Firewall.
Die Lösung dazu hast du ja auch schon vorgeschlagen
Aber nur eine Pass Regel zur pf Sense, sprich Router IP?
Und die lässt dann, da es durch die Firewall muss die RFC1918 doch wieder zu?
Ansonsten würden man ja immer noch an die GUI des Speedport kommen und ich wäre genauso weit.
Und die lässt dann, da es durch die Firewall muss die RFC1918 doch wieder zu?
Ansonsten würden man ja immer noch an die GUI des Speedport kommen und ich wäre genauso weit.
Du musst halt zusätzlich auch Dienste, welche von der Sense selbst bereitgestellt werden, freigeben. Das passiert über eine allow Regel vor der block Regel.
Z.b. DNS.
Z.b. DNS.
Also wie die Lockout Regel im Hauptnetz?
Ja. Dein Ziel lässt sich nicht vollständig mit einer Regel erreichen.
Das Ende vom Lied war es gab auch kein Internet mehr.
Klassischer Anfängerfehler und auch nicht nachgedacht das das laienhafte "kein Internet" in Wahrheit nur kein DNS bedeutet, denn mit der Regel hast du auch den DNS Server Zugang deinen Clients in den VLANs gekappt über die pfSense so das du keine Namen mehr auflösen kannst.Wenn du etwas intelligent nachgedacht hättest und im Diagnostics menü der pfSense einmal einben Ping auf eine Internet IP wie die 8.8.8.8 mit Absender IP WAN und lokale Interfaces gemacht hättest, hättest du gesehen das "das Internet" sehr wohl noch rennt du nur keine Hostnamen auflösen kannst.
Solche Banalitäten sollte man aber als Netzwerk Profi wie du es bist leicht erkennen können !
Fazit:
Es gilt immer "First match wins !" Reihenfolge zählt also !
Zuerst lässt du dann also immer UDP/TCP 53 zu aus dem jeweiligen Netz auf deine DNS Server IP, DANN kannst du deine Schrotschuss ACL drauf loslassen.
Es gibt viele Möglichkeiten mit dem Regelwerk sparsam umzugehen.
1.)
Intelligent subnetten ! Z.B.
Private Netze in den Bereich 192.168.0.0 bis 192.168.63.0 legen und alle Freundes- und öffentlichen Netze in die Netze: 192.168.64.0 bis 192.168.127.0
Dann reicht ein Filter der alle Netze 192.168.64.0 mit einer 18 Bit Maske 255.255.192.0 blockiert. Mit intelligentem Subnetting kann man sich zig unnütze Blocking Regeln ersparen.
2.)
Aliase erstellen wie du es auch schon gemacht hast. Die Speedport IP .100.1 ebenso dort mit aufnehmen, dann können Gäste, Freunde das GUI auch nicht erreichen
3.)
Kein DNS kappen ! Dann kann "dein Internet" natürlich nicht klappen und zum Troubleshooting immer primär das Ping, Traceroute und DNS Diagnostic Menü der pfSense nutzen !! Klappt es da weisst du sicher das der rest immer ein reines Client Problem ist.
Fazit: Strukturiert und strategisch vorgehen beim Troubleshooting !
Der DNS ist ja in erster Linie die pfSense selbst.
So könnte man die Clients ja auch darauf festnageln und alles zwingend über pfblocker e.t.c. leiten und entsprechend filtern.
Bei 2 erwähnst Du, die Speedport IP mit ins Alias aufnehmen.
Wenn ich mit der Gieskanne 100.0/24 mit erschlagen habe, braucht es das doch nicht, oder?
Ich verstehe es so, dass meine Deny all Regel funktioniert hätte, wenn ich vorweg Port 53 zur pfSense durchgelassen hätte.
Auch wenn beispielsweise der DNS vom Provider genutzt worden wäre, ginge das.
Der Client selbst darf nicht anfragen, da geblockt. Läuft es aber über die pfSense, ist es erlaubt.
Netzwerk Profi 🙈
Dass ich das nicht bin, weiß ich selbst. Gehobenes Laienwissen ist es vielleicht.
Das ist ja sogar ein Lehrberuf. Das ist schwer auf eine Ebene zu kommen.
Was ich mir unbedingt ansehen muss ist das Diagnostic Menü.
Das hatte ich bisher nie genutzt.
In dem Fall verband ich mich ins andere W-Lan. Handy zeigte kurz das Ausrufezeichen wegen fehlendem Internet, aber dann ging es.
In Wahrheit tat es das wohl nicht und es wurde LTE genutzt.
Aus Fehlern sollte man lernen.
So könnte man die Clients ja auch darauf festnageln und alles zwingend über pfblocker e.t.c. leiten und entsprechend filtern.
Bei 2 erwähnst Du, die Speedport IP mit ins Alias aufnehmen.
Wenn ich mit der Gieskanne 100.0/24 mit erschlagen habe, braucht es das doch nicht, oder?
Ich verstehe es so, dass meine Deny all Regel funktioniert hätte, wenn ich vorweg Port 53 zur pfSense durchgelassen hätte.
Auch wenn beispielsweise der DNS vom Provider genutzt worden wäre, ginge das.
Der Client selbst darf nicht anfragen, da geblockt. Läuft es aber über die pfSense, ist es erlaubt.
Netzwerk Profi 🙈
Dass ich das nicht bin, weiß ich selbst. Gehobenes Laienwissen ist es vielleicht.
Das ist ja sogar ein Lehrberuf. Das ist schwer auf eine Ebene zu kommen.
Was ich mir unbedingt ansehen muss ist das Diagnostic Menü.
Das hatte ich bisher nie genutzt.
In dem Fall verband ich mich ins andere W-Lan. Handy zeigte kurz das Ausrufezeichen wegen fehlendem Internet, aber dann ging es.
In Wahrheit tat es das wohl nicht und es wurde LTE genutzt.
Aus Fehlern sollte man lernen.
So könnte man die Clients ja auch darauf festnageln
Richtig. Noch besser AdGuard Home auf RasPi: https://github.com/AdguardTeam/AdGuardHome 😉Wenn ich mit der Gieskanne 100.0/24 mit erschlagen habe, braucht es das doch nicht, oder?
Absolut richtig !dass meine Deny all Regel funktioniert hätte, wenn ich vorweg Port 53 zur pfSense durchgelassen hätte.
Davon ist auszugehen !Viele verwechseln leider "das Internet" immer auch mit einem nicht funktionierenden DNS. Deshalb ist es immer sinnvoll eine nackte Internet IP wie z.B. die 8.8.8.8 mal zu pingen BEVOR man sagt "das Internet" geht nicht. 😉
Was ich mir unbedingt ansehen muss ist das Diagnostic Menü.
Absolut !!!Immer die allererste Adresse wenn es ums Troubleshooting geht !!!
Das hatte ich bisher nie genutzt.
Ein großer Fehler wie du siehst ! Genau deshalb gibt es dieses sehr sinnvolle Menü !Aus Fehlern sollte man lernen.
Weise Worte die immer wieder gültig sind....! 😉
Adguard Home habe ich noch gar nicht gehört.
Pi-Hole schon.
Bisher habe ich solch ein schauen noch gar nicht.
Jedoch wollte ich das zusätzliche System vermeiden.
Bevor ein Pi, würde ich es virtualisieren.
Lieber jedoch direkt auf der pfSense.
Ist davon eher abzuraten?
Pi-Hole schon.
Bisher habe ich solch ein schauen noch gar nicht.
Jedoch wollte ich das zusätzliche System vermeiden.
Bevor ein Pi, würde ich es virtualisieren.
Lieber jedoch direkt auf der pfSense.
Ist davon eher abzuraten?
Nein, beides ist OK.
Wobei man natürlich Adguard virtualisieren kann und als zweiten DNS direkt google e.t.c.
Sollte System 2 mit dem Blocker ausfallen, geht's immerhin noch weiter
Sollte System 2 mit dem Blocker ausfallen, geht's immerhin noch weiter
Zitat von @fnbalu:
Wobei man natürlich Adguard virtualisieren kann und als zweiten DNS direkt google e.t.c.
Sollte System 2 mit dem Blocker ausfallen, geht's immerhin noch weiter
Wobei man natürlich Adguard virtualisieren kann und als zweiten DNS direkt google e.t.c.
Sollte System 2 mit dem Blocker ausfallen, geht's immerhin noch weiter
Naja, Windows wird dann random mal den ersten und mal den zweiten DNS Server fragen.
Der zweite wird auch über die pfSense für die Clients mitgeliefert. Würde der interne der pfSense, der auf den Blocker zeigt ausfallen, würde ja ein Standard DNS weiter helfen
