7
Pfsense - Regel funktioniert im nativen Netz, nicht aber im VLan
Hallo zusammen!
Ich kämpfe seit gestern mit einem Problem in meinem Firewall-Regelwerk, von dem ich inzwischen glaube, dass es gar nicht an den Regeln liegt, sondern ich irgendwo anders einen Fehler eingebaut habe.
Nachdem ich mein Hausnetzwerk komplett umgekrempelt habe, habe ich auch endlich ein W-Lan für Gäste eingeführt, welches komplett autark sein soll. Grundsätzlich möchte ich im Bereich der W-Lan's fünf Bereiche
ID1: "blue" Der Admin-Bereich (tatsächlich kein W-Lan sondern Kupfer; hier hängen die APs und der Switch)
ID2: "IoT" Hier sollen später mal Bestandteile der Hausautomation landen.
ID5: "Media" Wie der Name schon sagt, W-Lan-Lautsprecher, TV, etc.
ID9: "Guest"
und irgendwann mal, wenn ich mein Problem gelöst habe, ein VLan10 für die hauseigenen Clients.
Wer mit dem Begriff "blue" etwas anfangen kann sieht, dass ich ursprünglich mit einer ipFire gearbeitet habe. Diese Trennung zwischen BLUE und GREEN (W-Lan / Kupfer) habe ich beibehalten. Ein Switch für den W-Lan-Bereich, ein Switch für den Kupfer-Bereich.
Derzeit teste ich mit einem mobilen Endgerät, welches im Admin-Bereich via DHCP eine feste IP zugewiesen bekommt.
Konfiguration des Admin-Bereichs:
(den Rest vom DHCP hab ich weggelassen, da ist nichts eingetragen)
Ich bilde mir ein, dass ich mit diesen beiden Regeln aktuell jedem Gerät in diesem Netzwerk ins WAN zu gelangen, nicht aber in die anderen privaten Netzwerke. Bei meiner Testerei hat's jedenfalls wie gewünscht funktioniert.
Jetzt habe ich im VLan9 genau das gleiche Spielchen getrieben:
(auch hier ist weiter nichts eingetragen)
Anhand der jetzt zugewiesenen IP-Adresse aus dem Bereich des V-Lan9 sehe ich, dass die Zuordnung meines Testgeräts klappt (die W-Lan's am AP sind auch entsprechend zugeordnet).
Jedoch komme ich, im Gegensatz zum Admin-Netzwerk, hier mit meinem Testgerät überall hin. Lasse ich dem Gerät im Guest-Bereich probeweise eine feste IP zuweisen, ändert sich auch nichts.
Ach ja, bevor ich es vergesse, folgende Regeln gibt es noch:
Das ist der Standard für die WAN-Schnittstelle.
Das Admin-Netzwerk und das Guest-Netzwerk teilen sich sowohl an der pfsense, als auch am Switch den gleichen physikalischen Port.
Sehe ich den Wald vor lauter Bäumen nicht? Warum funktionierts im "nativen" Netzwerk, nicht aber im V-Lan?
Ich kämpfe seit gestern mit einem Problem in meinem Firewall-Regelwerk, von dem ich inzwischen glaube, dass es gar nicht an den Regeln liegt, sondern ich irgendwo anders einen Fehler eingebaut habe.
Nachdem ich mein Hausnetzwerk komplett umgekrempelt habe, habe ich auch endlich ein W-Lan für Gäste eingeführt, welches komplett autark sein soll. Grundsätzlich möchte ich im Bereich der W-Lan's fünf Bereiche
ID1: "blue" Der Admin-Bereich (tatsächlich kein W-Lan sondern Kupfer; hier hängen die APs und der Switch)
ID2: "IoT" Hier sollen später mal Bestandteile der Hausautomation landen.
ID5: "Media" Wie der Name schon sagt, W-Lan-Lautsprecher, TV, etc.
ID9: "Guest"
und irgendwann mal, wenn ich mein Problem gelöst habe, ein VLan10 für die hauseigenen Clients.
Wer mit dem Begriff "blue" etwas anfangen kann sieht, dass ich ursprünglich mit einer ipFire gearbeitet habe. Diese Trennung zwischen BLUE und GREEN (W-Lan / Kupfer) habe ich beibehalten. Ein Switch für den W-Lan-Bereich, ein Switch für den Kupfer-Bereich.
Derzeit teste ich mit einem mobilen Endgerät, welches im Admin-Bereich via DHCP eine feste IP zugewiesen bekommt.
Konfiguration des Admin-Bereichs:
Jetzt habe ich im VLan9 genau das gleiche Spielchen getrieben:
Jedoch komme ich, im Gegensatz zum Admin-Netzwerk, hier mit meinem Testgerät überall hin. Lasse ich dem Gerät im Guest-Bereich probeweise eine feste IP zuweisen, ändert sich auch nichts.
Ach ja, bevor ich es vergesse, folgende Regeln gibt es noch:
Das Admin-Netzwerk und das Guest-Netzwerk teilen sich sowohl an der pfsense, als auch am Switch den gleichen physikalischen Port.
Sehe ich den Wald vor lauter Bäumen nicht? Warum funktionierts im "nativen" Netzwerk, nicht aber im V-Lan?
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: 7559063480
Url: https://administrator.de/forum/pfsense-regel-funktioniert-im-nativen-netz-nicht-aber-im-vlan-7559063480.html
Ausgedruckt am: 27.12.2024 um 09:12 Uhr
7 Kommentare
Neuester Kommentar
Den ersten fatalen Fehler den du begangen hast ist eine falsche DHCP Range zu konfigurieren. 
Mit einem 24er Prefix solltest du niemals den gesamten Bereich von .1 bis .254 festlegen. .1 schon mal gar nicht denn das ist die feste, statische IP der Firewall selber die der DHCP Server ja deshalb niemals vergeben sollte. Best Practise ist ohnehin immer an den "Rändern" freie IP Adressen für ggf. statische Adressierung als Puffer freizulassen. Besser wäre also eine Range von .5 bis .250. In jeden Falle muss die .1 immer exkludiert werden in der Range der Client Pool Adressen.
Zusätzlich sollte dort die Lease Time auf Local statt UTC gesetzt sein.
Der zweite Kardinalsfehler den du (und das als kundiger Firewall Admin?!) begangen hast ist ein grundlegender Denkfehler beim Ruleset.
Es gilt immer: "First match wins!" sprich der erste positive Hit im Regelwerk bewirkt das der Rest des Regelwerkes NICHT mehr abgearbeitet wird. Das war auch bei deiner ipFire schon so!
Fazit: Reihenfolge zählt im Regelwerk! Hiesige Tutorials weisen immer entsprechend darauf hin.
Wenn deine erste Regel also ein PASS mit allen Source Adressen des GUESTBLUE Netzes ist, dann kann die 2te Regel folglich niemals greifen weil die erste immer positiv ist! Einfache Logik...
Davon das VLAN spezifische Regelwerke logischerweise auch immer an den dazu entsprechenden VLAN Interfaces und nicht am Parent Interface konfiguriert werden gehen wir jetzt bei dir mal aus?!
Passe dein o.a. Regelwerk also in der richtigen Reihenfolge an, dann funktionieren deine Regeln auch sofort und wie sie sollen!
Mit einem 24er Prefix solltest du niemals den gesamten Bereich von .1 bis .254 festlegen. .1 schon mal gar nicht denn das ist die feste, statische IP der Firewall selber die der DHCP Server ja deshalb niemals vergeben sollte. Best Practise ist ohnehin immer an den "Rändern" freie IP Adressen für ggf. statische Adressierung als Puffer freizulassen. Besser wäre also eine Range von .5 bis .250. In jeden Falle muss die .1 immer exkludiert werden in der Range der Client Pool Adressen.
Zusätzlich sollte dort die Lease Time auf Local statt UTC gesetzt sein.
Der zweite Kardinalsfehler den du (und das als kundiger Firewall Admin?!) begangen hast ist ein grundlegender Denkfehler beim Ruleset.
Es gilt immer: "First match wins!" sprich der erste positive Hit im Regelwerk bewirkt das der Rest des Regelwerkes NICHT mehr abgearbeitet wird. Das war auch bei deiner ipFire schon so!
Fazit: Reihenfolge zählt im Regelwerk! Hiesige Tutorials weisen immer entsprechend darauf hin.
Wenn deine erste Regel also ein PASS mit allen Source Adressen des GUESTBLUE Netzes ist, dann kann die 2te Regel folglich niemals greifen weil die erste immer positiv ist! Einfache Logik...
Davon das VLAN spezifische Regelwerke logischerweise auch immer an den dazu entsprechenden VLAN Interfaces und nicht am Parent Interface konfiguriert werden gehen wir jetzt bei dir mal aus?!
Passe dein o.a. Regelwerk also in der richtigen Reihenfolge an, dann funktionieren deine Regeln auch sofort und wie sie sollen!
Hallo aqui!
Ich habe bei beiden DHCPs einen Bereich von .200 bis .250 eingetragen. Aus diesem Bereich wird auch die IP dem Client zugeteilt. Unter verfügbarer Range wird doch nur dargestellt, was mir für einen DHCP zur Verfügung stehen könnte; Vorgabe wird doch dann unter "Bereich" gesetzt?
Und das bringt mich EXAKT zu dem Punkt den ich nicht verstehe:
An meiner Konfiguration erklärt, so wie du es sagst und so wie ich es verstehe:
Trifft die erste Regel zu, also hier das Scheunentor, dann wird die zweite Regel nicht mehr geprüft. Heißt bei meiner Config: Er will ins WAN, passt. Er will in ein anderes Netz, passt auch. Zweite Regel (!WAN) wird somit ignoriert.
Nach der Vorgabe "ohne irgendeine Regel wird alles blockiert", sollte mir ja die Regel "!WAN" ausreichen - diese sagt ja "verbiete alles außer WAN"; ist ja invertiert. Somit habe ich explizit WAN erlaubt und alles andere verboten.
UND GENAU DAS FUNKTIONIERT NICHT. Drehe ich diese beiden Regeln um, also Scheunentor als zweite Regel und "erlaube nur WAN" als erste Regel, dann lässt er mich nicht mehr ins WAN, sondern nur auf die anderen Subnetze. Arbeite ich nur mit der Regel "!WAN" komme ich nirgendwo mehr hin((((
EDIT:
Um es nochmal mit anderen Worten rüber zu bringen:
Mit der falschen Reihenfolge im Admin-Netz (blue, igc1) funktioniert es so wie es soll. Im VLan auf igc1.9 funktioniert entweder alles oder nichts. Egal ob ein oder zwei Regeln und bei zwei Regeln in welcher Reihenfolge diese stehen. Deshalb gehe ich ja davon aus, dass ich woanders Mist gebaut habe und die Firewall vielleicht umgehe. Ich habe auch schon probiert, ob ich mit einem Client irgendwo zwischen den Netzen "springen" kann ohne die Firewall zu bemühen. Das ist aber auch anscheinend nicht der Fall
Zitat von @aqui:
Den ersten fatalen Fehler den du begangen hast ist eine falsche DHCP Range zu konfigurieren. Mit einem 24er Prefix solltest du niemals den gesamten Bereich von .1 bis .254 festlegen. .
Den ersten fatalen Fehler den du begangen hast ist eine falsche DHCP Range zu konfigurieren. Mit einem 24er Prefix solltest du niemals den gesamten Bereich von .1 bis .254 festlegen. .
Ich habe bei beiden DHCPs einen Bereich von .200 bis .250 eingetragen. Aus diesem Bereich wird auch die IP dem Client zugeteilt. Unter verfügbarer Range wird doch nur dargestellt, was mir für einen DHCP zur Verfügung stehen könnte; Vorgabe wird doch dann unter "Bereich" gesetzt?
Der zweite Kardinalsfehler den du (und das als kundiger Firewall Admin?!) begangen hast ist ein grundelgender Denkfehler beim Ruleset.
Es gilt immer: "First match wins!" sprich der erste positive Hit im Regelwerk bewirkt das der Rest des Regelwerkes NICHT mehr abgearbeitet wird. Das war auch bei deiner ipFire schon so!
Fazit: Reihenfolge zählt im Regelwerk! Hiesige Tutorials weisen immer entsprechend darauf hin.
Wenn deine erste Regel also ein PASS mit allen Source Adressen des BLUE Netzes ist dann kann die 2te Regel niemals greifen weil die erste immer positiv ist! Einfache Logik...
Es gilt immer: "First match wins!" sprich der erste positive Hit im Regelwerk bewirkt das der Rest des Regelwerkes NICHT mehr abgearbeitet wird. Das war auch bei deiner ipFire schon so!
Fazit: Reihenfolge zählt im Regelwerk! Hiesige Tutorials weisen immer entsprechend darauf hin.
Wenn deine erste Regel also ein PASS mit allen Source Adressen des BLUE Netzes ist dann kann die 2te Regel niemals greifen weil die erste immer positiv ist! Einfache Logik...
Und das bringt mich EXAKT zu dem Punkt den ich nicht verstehe:
An meiner Konfiguration erklärt, so wie du es sagst und so wie ich es verstehe:
Trifft die erste Regel zu, also hier das Scheunentor, dann wird die zweite Regel nicht mehr geprüft. Heißt bei meiner Config: Er will ins WAN, passt. Er will in ein anderes Netz, passt auch. Zweite Regel (!WAN) wird somit ignoriert.
Nach der Vorgabe "ohne irgendeine Regel wird alles blockiert", sollte mir ja die Regel "!WAN" ausreichen - diese sagt ja "verbiete alles außer WAN"; ist ja invertiert. Somit habe ich explizit WAN erlaubt und alles andere verboten.
UND GENAU DAS FUNKTIONIERT NICHT. Drehe ich diese beiden Regeln um, also Scheunentor als zweite Regel und "erlaube nur WAN" als erste Regel, dann lässt er mich nicht mehr ins WAN, sondern nur auf die anderen Subnetze. Arbeite ich nur mit der Regel "!WAN" komme ich nirgendwo mehr hin
((((Davon das VLAN spezifische Regelwerke logischerweise auch immer an den dazu entsprechenden VLAN Interfaces und nicht am Parent Interface konfiguriert werden gehen wir jetzt bei dir mal aus?!
Yeah, deshalb habe ich die "Einführung" mit meiner Stuktur geschrieben. BLUE, also igc1 ist das native Netz, ohne Tagging. Das GuestBLUE ist getagged und somit die igc1.9. Für dieses ist auch die sichtbare SSID konfiguriert auf die ein Gast zugreifen darf.Passe dein o.a. Regelwerk also in der richtigen Reihenfolge an, dann funktioniert auch dein Regelwerk sofort und wie es soll!
Eben ja leider nicht, sonst würde ich ja nicht davon ausgehen, dass ich woanders Mist gebaut habe...EDIT:
Um es nochmal mit anderen Worten rüber zu bringen:
Mit der falschen Reihenfolge im Admin-Netz (blue, igc1) funktioniert es so wie es soll. Im VLan auf igc1.9 funktioniert entweder alles oder nichts. Egal ob ein oder zwei Regeln und bei zwei Regeln in welcher Reihenfolge diese stehen. Deshalb gehe ich ja davon aus, dass ich woanders Mist gebaut habe und die Firewall vielleicht umgehe. Ich habe auch schon probiert, ob ich mit einem Client irgendwo zwischen den Netzen "springen" kann ohne die Firewall zu bemühen. Das ist aber auch anscheinend nicht der Fall
Ich habe bei beiden DHCPs einen Bereich von .200 bis .250 eingetragen.
OK, sorry da hast du natürlich Recht was die available Range anbetrifft.Heißt bei meiner Config: Er will ins WAN, passt.
Nicht ganz...Richtig ist: Alles was eine Absender IP von GUESTBLUE hat und zu jeder x-beliebigen Ziel IP will darf passieren und erzeugt einen positiven Hit für alles was aus dem GUESTBLUE an ein anderes Ziel will.
Zweite Regel (!WAN) wird somit ignoriert.
Richtig, da diese nach der ersten Regel steht kann sie niemals mehr greifen.Außerdem ist "!WAN" auch kompletter Unsinn weil es ja nur Pakete blockt die in genau DAS spezifische IP Netzwerk am WAN Port wollen.
Solche Pakete gibt es so gut wie nie. "WAN" meint logischerweise nicht alle IP Adressen im Internet sondern nur das WAN Port IP Netz. Ggf. machst du auch hier einen "Denkfehler"?!
Gut, diese Regel kann Sinn machen wenn du deine Firewall in einer Router Kaskade betreibst und du verhindern möchtest das Traffic an Geräte in deinem Koppelnetz gesendet werden. Dennoch stimmt dann aber die Reihenfolge nicht.
Da du leider keinerlei Aussagen zum Netzdesign machst kann man hier aber nur Kristallkugeln.
Normal gehören auch keine Endgeräte ins Koppelnetz bei einer Kaskade.
Fakt ist aber das diese Regel, egal ob sinnig oder nicht, niemals greifen kann wegen der falschen Reihenfolge nach der "Scheunentor" Regel davor.. Deny oder Negationsregeln liegen logischerweise immer VOR den ...zu any Regeln damit sie greifen können.
sollte mir ja die Regel "!WAN" ausreichen
Kommt drauf an. Siehe Erklärung oben. Ohne ein Kaskadendesign wäre diese Regel natürlich sinnfrei. Mal abgesehen von der falschen Reihenfolge die sie dann so oder so sinnfrei macht. dann lässt er mich nicht mehr ins WAN
Logisch, denn damit blockst du ja auch das Default Gateway...zumindestens in einer Kaskade. Bei direkter Provider Connection dann das Gateway des Providers.Die Regel besagt ja...
"Blockiere alles was eine v4 und v6 Absender IP aus dem "GUESTBLUE" IP Netz hat und dessen Ziel IP nicht im WAN Port IP Netz liegt"
Logisch gesehen sind das dann weltweit alle IP Adressen außer denen die im WAN Port IP Netz liegen. Mit anderen Worten du blockierst dir alles an Internet IPs nur Ziel IP Adressen aus dem WAN Port IP Netz dürften passieren.
Das solch unsinnige Regel dann in die Hose gehen muss wenn diese Regel an erster Stelle steht sagt einem auch schon der gesunde IT Verstand!
Die Frage ist WAS du mit dieser Regel denn überhaupt erreichen willst?? (Mit der hast du ja den Mist gebaut!)
Mit der falschen Reihenfolge im Admin-Netz (blue, igc1) funktioniert es so wie es soll.
Das musst du nicht wiederholen, denn wie oben mehrfach gesagt ist das klar. Diese Scheunentor Regel lässt alles durch, positiver Hit...danach wird nix mehr abgearbeitet an Regeln.Es bleibt dabei: WAS soll diese 2te Regel genau bewirken??
@aqui
Vorweg, bevor ich da darauf eingehe, meine Architektur (ich hab's weggelassen, weil ich dacht es wär nicht relevant):
Vodafone Kabel-Box im Bridge-Mode -> pfSense -> interne Netze (drei "interne" NICs: Kupfer, WLan und DMZ).
Ich habe keine Zugangsdaten, sondern werde über die MAC der Kabelbox legitimiert. Von der Kabelbox geht nur noch der VoIP-Ast weg, sonst nix.
Die Kabelbox ist an der WAN-Nic angeschlossen - Konfiguration der pfSense: DHCP und DHCPv6 (Bogon und Privat geblockt), Die pfSense bekommt meine extern zugewiesene IP "durchgereicht". Das war mir wichtig. In den Routen bekomme ich die .254 meiner ext. IP als Gateway angezeigt. Ebenso zeigt mir das Dashboard die tatsächliche externe IP als WAN-IP an.
So, jetzt kommen zwei Stolperfallen, auf die ich aus Unachtsamkeit anscheinend reingetappt bin:
Bei der ipfire konntest du für jede NIC vorgeben, was du von Haus aus haben möchtest wenn KEINE Regel definiert ist: Allow, drop, reject. Das hatte ich für LAN -> WAN auf Allow. Somit wurden mir nur Versuche geblockt, welche explizit eine DENY-Regel eingetragen hatten. Das heißt, du konntest entweder nur mit einem positiven oder negativen Treffer arbeiten. Ein "Treffer" halt für die Regel. Du brauchtest bei der Grundeinstellung "ALLOW" keine "ALLOW-Regel" für das Ziel. Somit ging ich davon aus, dass eine ALLOW-Regel hier nicht als Treffer zählt.
Den Haken "invert match" habe ich so bewertet, dass du damit das Ziel oder die Quelle negiert hast. Bei einer Regel "ALLOW GuestBLUE -> WAN" gehe ich davon aus, dass diese Regel alles von GuestBLUE ins WAN erlaubt und bei einer Regel "ALLOW GuestBLUE -> !WAN" alles erlaubt, AUßER den Zugriff auf das WAN. Habe ich also (incl WAN) fünf Netze, dann spare ich mir für vier Netze die DENY-Regeln. Aufgrund des Denkfehlers wäre aber dann wohl die richtige Konfiguration für einen Zugriff NUR in das Internet
- DENY any GuestBLUE -> Netz 1
- DENY any GuestBLUE -> Netz 2
- ...
- ALLOW any GuestBLUE -> WAN?
So habe ich mein Gästenetz jetzt konfiguriert und es funktioniert. Vielen Dank hierfür großer Meister der pfSense!
Womit ich jetzt noch am Schlauch stehe, und da bringen mir die Threads auch nix, sonst hätte ich ja den Fehler nicht gemacht:
xxx net bedeutet für mich das Netzwerk und xxx address bedeutet für mich ein bestimmter Client. Warum schlägt dann die Regel ALLOW GuestBLUE -> WAN net fehl, wenn das doch das Netzwerk ist von dem mir mein Provider die IP zuweist? Würde das heißen, dass ich nur auf die "anderen Kunden" an dem Provider-GW zugreifen könnte, nicht aber auf das Internet an sich? Wie konfiguriere ich das dann? Ich habe ja weder PPPirgendwas, noch L2TP?
Vorweg, bevor ich da darauf eingehe, meine Architektur (ich hab's weggelassen, weil ich dacht es wär nicht relevant):
Vodafone Kabel-Box im Bridge-Mode -> pfSense -> interne Netze (drei "interne" NICs: Kupfer, WLan und DMZ).
Ich habe keine Zugangsdaten, sondern werde über die MAC der Kabelbox legitimiert. Von der Kabelbox geht nur noch der VoIP-Ast weg, sonst nix.
Die Kabelbox ist an der WAN-Nic angeschlossen - Konfiguration der pfSense: DHCP und DHCPv6 (Bogon und Privat geblockt), Die pfSense bekommt meine extern zugewiesene IP "durchgereicht". Das war mir wichtig. In den Routen bekomme ich die .254 meiner ext. IP als Gateway angezeigt. Ebenso zeigt mir das Dashboard die tatsächliche externe IP als WAN-IP an.
So, jetzt kommen zwei Stolperfallen, auf die ich aus Unachtsamkeit anscheinend reingetappt bin:
Bei der ipfire konntest du für jede NIC vorgeben, was du von Haus aus haben möchtest wenn KEINE Regel definiert ist: Allow, drop, reject. Das hatte ich für LAN -> WAN auf Allow. Somit wurden mir nur Versuche geblockt, welche explizit eine DENY-Regel eingetragen hatten. Das heißt, du konntest entweder nur mit einem positiven oder negativen Treffer arbeiten. Ein "Treffer" halt für die Regel. Du brauchtest bei der Grundeinstellung "ALLOW" keine "ALLOW-Regel" für das Ziel. Somit ging ich davon aus, dass eine ALLOW-Regel hier nicht als Treffer zählt.
Den Haken "invert match" habe ich so bewertet, dass du damit das Ziel oder die Quelle negiert hast. Bei einer Regel "ALLOW GuestBLUE -> WAN" gehe ich davon aus, dass diese Regel alles von GuestBLUE ins WAN erlaubt und bei einer Regel "ALLOW GuestBLUE -> !WAN" alles erlaubt, AUßER den Zugriff auf das WAN. Habe ich also (incl WAN) fünf Netze, dann spare ich mir für vier Netze die DENY-Regeln. Aufgrund des Denkfehlers wäre aber dann wohl die richtige Konfiguration für einen Zugriff NUR in das Internet
- DENY any GuestBLUE -> Netz 1
- DENY any GuestBLUE -> Netz 2
- ...
- ALLOW any GuestBLUE -> WAN?
Womit ich jetzt noch am Schlauch stehe, und da bringen mir die Threads auch nix, sonst hätte ich ja den Fehler nicht gemacht:
xxx net bedeutet für mich das Netzwerk und xxx address bedeutet für mich ein bestimmter Client. Warum schlägt dann die Regel ALLOW GuestBLUE -> WAN net fehl, wenn das doch das Netzwerk ist von dem mir mein Provider die IP zuweist? Würde das heißen, dass ich nur auf die "anderen Kunden" an dem Provider-GW zugreifen könnte, nicht aber auf das Internet an sich? Wie konfiguriere ich das dann? Ich habe ja weder PPPirgendwas, noch L2TP?
weil ich dacht es wär nicht relevant
Ist es eigentlich auch aber wenn man verstehen will was du mit deinen wirren Regeln erreichen willst wäre es hilfreich man kennt es. Vodafone Kabel-Box im Bridge-Mode -> pfSense -> interne Netze
Sprich die FB hält dann am WAN Port die öffentliche Provder IP, richtig?Damit wäre den "!WAN" Regel dann aber völlig absurd.
sondern werde über die MAC der Kabelbox legitimiert.
Das ist bekannt, der WAN Port der pfSense ist dann im DHCP Client Mode und zieht sich eine IP aus dem Vodkafön Netz. (Konfiguration der pfSense: DHCP und DHCPv6)Ebenso zeigt mir das Dashboard die tatsächliche externe IP als WAN-IP an.
So sollte es bilderbuchmässig auch sein! 👍Bei der ipfire konntest du für jede NIC vorgeben
Das geht bei pfSense / OPNsense nicht. Dort gilt wie allgemein Firewall üblich im Default: Deny any anyOK, da hat dich deine an sich richtige IPFire Logik dann blöderweise aufs Glatteis geführt.
Den Haken "invert match" habe ich so bewertet, dass du damit das Ziel oder die Quelle negiert hast.
Das ist auch bei pfSense / OPNsense identisch.Nur die Logik Blocke alles was nicht WAN Netz ist hat dich dann vermutlich etwas verwirrt...
Nur...was sollte diese eigentlich unsinnige Regel wenn deine Firewall direkt am Providernetz hängt?!Bei einer Regel "ALLOW GuestBLUE -> WAN" gehe ich davon aus, dass diese Regel alles von GuestBLUE ins WAN erlaubt
Genau richtig!Nur....was erwartest du denn nur im Zuliefer IP Netz der Vodafone für Endgeräte??
Du hast hier vermutlich irrig angenommen das das schon das "gesamte" Internet ist, was natürlich Unsinn ist denn im den User IP Segment der Vodkafön gibts für dich sicher keinerlei Hosts die es erstrebenswert machen darauf zuzugreifen.
Mit anderen Worten...diese Regel hat doch gar keinen praktischen Sinn und ist mehr oder minder überflüssig.
und bei einer Regel "ALLOW GuestBLUE -> !WAN" alles erlaubt, AUßER den Zugriff auf das WAN.
Jepp, auch das ist so richtig. Nur das du oben keine ALLOW sondern eine DENY Regel konfiguriert hast! Erkennbar am roten X. Die dreht natürlich dann alles wieder um.
Warum man dann den Zugriff auf das interne Vodafon Verteilernetz (und nur dieses!) nochmal extra erlauben will bleibt schleierhaft. Wie gesagt...vermutlich der fatale Denkfehler das WAN = Internet ist?!
DENY any GuestBLUE -> Netz 1
Diese Einzelfrickelei kannst du dir ersparen.- Erzeuge dir in den Regeln einen Alias z.B. "Private_Netze" und packe die folgenden Netze darunter:
- 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
- Am Gastnetz ist deine erste Regel dann ein DENY GuestBLUE -> Alias und als zweite dann ALLOW GuestBLUE -> Any Damit blockst du dann den Zugriff auf alle privaten IP Netze die du intern betreibst oder ggf. mal einrichtest. Achtung: Die IP der Firewall selber musst du ggf. für DNS (UDP/TCP 53) und wenn du deine Gäste mit einem [ Captive Portal] und Einmalpasswörter abgetrennt hast dann auch für den Portalport! Hier hilft immer das Firewall Log um zu sehen WAS geblockt wird. Achtung: Logging dazu immer auf "Aktuellsten Eintrag zuerst" im Logging Setup stellen!
Wenn du deine Gäste noch weiter in den Diensten einschränken willst machst du das auch über einen Port Alias.
Keep ist simple stupid! 😉
Vielen Dank hierfür
Immer gerne!xxx net bedeutet für mich das Netzwerk und xxx address bedeutet für mich ein bestimmter Client.
Absolut richtig!Warum schlägt dann die Regel ALLOW GuestBLUE -> WAN net fehl
Annahme ist das du hier vermutlich laienhaft angenommen hast WAN_net ist gleichzusetzen mit dem Internet, was natürlich völliger Unsinn ist.LAN_net bezeichnet ja ebenso auch einzig nur dein IP Netz am LAN Port und nicht alles was du als Netze am LAN Port hast.
Da liegt vermutlich dein fataler Denkfehler, kann das sein?
Angenommen du hast am Vodafon WAN Port die IP 88.11.22.33 /24 bekommen dann bezeichnet der Alias "WAN_net" lediglich das IP Netz: 88.11.22.0 aber eben nicht das gesamte Internet.
Ein laienhafter Denkfehler der oft begangen wird bei Filterlisten.
Das heisst deine Regel "ALLOW GuestBLUE -> WAN_net" erlaubt dann den IP Pakete mit der Absender IP GuestBLUE ins IP Netz 88.11.22.0.
Die Frage ob das Sinn macht oder nicht kannst du dir vermutlich selber beantworten?! 😉
Würde das heißen, dass ich nur auf die "anderen Kunden" an dem Provider-GW zugreifen könnte, nicht aber auf das Internet an sich?
Der Kandidat hat 100 Punkte!!! Nur das 88er Netz ist erlaubt.Wie konfiguriere ich das dann? Ich habe ja weder PPPirgendwas, noch L2TP?
Was denn??Das die Nutzer von GuestBLUE nicht ins Vodafone Kunden IP Netz 88.11.22.0 können?
Mal ehrlich: Who cares! Kann dir doch völlig Wumpe sein wenn die das machen und Vodkafön seine Endgeräte dort nicht angriffssicher konfiguriert. Warum willst du gerade interne Vodafone Netze vor deinen Gästen schützen??
Ist sicher edel von dir gemeint nur von Vodafone darfst du keinen Dank erwarten.
Dann müsstest du ggf. auch das ganze Internet vor deinen Gästen schützen.... Du erkennst sicher selber den Sinn und Unsinn solcher Regeln?!
Auf andere Kunden Endgeräte kannst du da eh nicht zugreifen. Vodafone verwendet, wie alle anderen Provider auch, dort immer isolated VLANs mit Portisolation!
https://en.wikipedia.org/wiki/Private_VLAN
Aqui, vielen Dank für deine Hilfe!
Ja, da waren doch einige Denkfehler drinnen, egal ob flüchtig gelesen oder darauf verzichtet zu lesen - weil, "ich hab's ja scho mal g'macht, ich kann's ja"...
Das ganze Gedöns um das WAN herum entstand ja nur dadurch, da ich davon ausging, das ist das Internet. Aber ich hab schon gemerkt, du hast es mit der richtigen Portion Ironie und Sarkasmus aufgenommen
Es läuft, Dank deiner Hilfe! Und die Family ist auch wieder glücklich ("Papa, du hast das Internet kaputt gemacht").
Hab jetzt schon wieder das nächste Problem (bei dem du mir sicher helfen kannst), aber das wäre hier oT - also neuer Thread.
Ja, da waren doch einige Denkfehler drinnen, egal ob flüchtig gelesen oder darauf verzichtet zu lesen - weil, "ich hab's ja scho mal g'macht, ich kann's ja"...
Das ganze Gedöns um das WAN herum entstand ja nur dadurch, da ich davon ausging, das ist das Internet. Aber ich hab schon gemerkt, du hast es mit der richtigen Portion Ironie und Sarkasmus aufgenommen
Es läuft, Dank deiner Hilfe! Und die Family ist auch wieder glücklich ("Papa, du hast das Internet kaputt gemacht").
Hab jetzt schon wieder das nächste Problem (bei dem du mir sicher helfen kannst), aber das wäre hier oT - also neuer Thread.
da ich davon ausging, das ist das Internet.
In diese Falle tappen viele Anfänger... 😉 Aber klasse das das nun gefixt ist und du etwas über IP Adressierung gelernt hast was dir keiner mehr nehmen kann.("Papa, du hast das Internet kaputt gemacht").
🤣...das kennt jeder Heim Adminhttp://www.onlinewahn.de/ende.htm
Hab jetzt schon wieder das nächste Problem
Wir sind gespannt...
