[solved] Problem / Verständisfrage bezüglich VLANs und Regelwerk - SG-3100
-
@johndo
https://docs.netgate.com/pfsense/en/latest/firewall/firewall-rule-basics.html konzentriert lesen bis du es verstehst. Wenn das nicht reicht lies das Buch:
https://docs.netgate.com/pfsense/en/latest/book/firewall/index.html -
@Grimson
Hi,diese Antwort hilft mir jetzt so nicht weiter. Sind den meine Regeln falsch?
-
Hi,
sorry aber ich komme leider nicht weiter. Wie kann ich den eine Regel erstellen die allen Clients das surfen im Internet ermöglicht aber nicht gleichzeitig auf die internen Netze zugreifen darf?
Ich habe zum Beispiel keine Any Regel erstellt sondern explizit gesagt ich möchte von meinem LAN Net zum WAN Net und zwar alles. Aber dann funktioniert kein Internetzurgiff mehr.
Wenn ich einzelne Services freischalte zum Beispiel Port 80 und 443 dann gehts das zwar raus aber diese Ports kann ich dann auch wieder in einem Internen Netz erreichen.
Hat mal jemand einen Screenshot wie das aussehen kann?
-
Hallo,
ja, "WAN net" ist nur das Subnetz, das am WAN Interface konfiguriert ist, nicht das ganze Internet. Dafür braucht es "any" als Ziel in der Erlauben-Regel. Um Zugriffe auf interne Ziele zu unterbinden, muss du noch eine Block-Regel erstellen und diese vor die Pass-Regel setzen.
Best Practice um interne Zugriffe generell zu verbieten ist es einen Alias zu erstellen, der sämtliche RFC 1918 Netze beinhaltet (angenommen, du verwendest intern ausschließlich RFC 1918), und diesen als Ziel in der Block-Regel zu verwenden, die an oberster Position in der Liste sitzt.
Die Regeln werden in pfSense immer von oben nach unten auf Treffer überprüft und bei Zutreffen angewandt und die weiteren ignoriert.Hinter dieser Block-Regel kannst du dann einzelnen IPs oder Subnetzen explizit Zugriff mit Pass-Regeln erlauben.
@johndo said in Problem / Verständisfrage bezüglich VLANs und Regelwerk - SG-3100:
Wenn ich nun mit meinem Notebook (LAN3 - VLAN 300 - 10.0.3.50/24) auf meine Synology (DMZ - kein VLAN - 10.1.1.50/24) funktoniert der Zugriff ebenfalls? Das verwirrt mich, da ich keine Regel auf dem OPT1 Interface erstellt habe? Ich wäre nun davon ausgegangen das ich eine eingehende Regel erstellen muss der dies zulässt?
Die Regeln sind auf pfSense immer an jenen Interfaces zu erstellen, an welchen der Traffic in die Firewall reinkommt. Für diesen Zugriff ist also der Regelsatz am LAN3 zuständig.
-
@johndo Was @Grimson meinte ist schon richtig wenngleich etwas unhöflich verpackt. Mach dich mit der Regelvergabe vertraut und wie sie in pfSense bzw. pf generell funktioniert. Andere Firewalls anderes Prozedere.
Wichtige Stichpunkte:
- Es gibt im Normalfall keinen Grund für "ausgehende" Regeln, die man vielleicht bei anderen Produkten nutzt. Ausgehend (aus Interface Sicht also von pfSense nach irgendwohin raus aus der Schnittstelle) ist default erlaubt, da es ja erstmal irgendwo reinkommen muss. Daher:
- Es wird eingehend gefiltert. Wo ein Paket zuerst auf die pfSense trifft wird die Filterregel erstellt und der Zugriff behandelt. Egal wo das Paket danach hingeht.
- NAT wird vor Filterregeln abgearbeitet, sollte also ein Paket umgeschrieben werden (Port Forwarding) dann wird seine "neue" bzw. Ziel-IP im Filter verwendet auch wenn man dann bspw. eine private Adresse auf dem WAN als Destination hat.
- Regeln werden top-to-bottom abgearbeitet und sind alle "quick" (in PF-Sprache). Heißt sie werden bei einem Match sofort angewendet und die Regelverarbeitung abgebrochen. Ein Paket, dass auf die 2. Regel eines Regelsatzes trifft, wird nicht mehr weiter nach unten gehen um dort ggf. doch noch geblockt zu werden. Reihenfolge also entsprechend konfigurieren und verschieben.
Wie @viragomann also völlig richtig meint: Dein Hauptproblem das "Internet" (meistens "any") zu definieren ist im Normalfall alle im LAN verwendeten Netze - oder einfach alle RFC1918 privaten Netze - zu blocken und den Rest freizugeben. Wird die Sense im Normalfall noch als DHCP, DNS und NTP im VLAN/LAN/Netz verwendet ergibt sich mit Abschirmung alles LANs voneinander meist das hier:
- pass udp from <vlan_net> to <this_firewall> port 53 (DNS)
- pass udp from <vlan_net> to <this_firewall> port 123 (NTP)
- block any from <vlan_net> to RFC1918 (letzteres ist ein Alias mit 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
- pass any from <vlan_net> to any
Obiges Beispiel ist auf dem LAN noch ergänzt durch die Anti-Lockout Regel damit man sich nicht von der UI aussperrt, aber im Wesentlichen ist das so ein Standard Set. 1) und 2) kann man natürlich noch zusammenfassen wenn man ein Port Alias anlegt in welchem 53 und 123 enthalten sind ;) Dann klappts mit 3 Regeln :)
Grüße
-
Man kann auch auch eine Pass-Regel mit Invert Match erstellen und diese an Ende packen. Damit wird nur Internet erlaubt. Man spart sich dadurch die any to any Regel.
pass any from vlan to NOT rfc1918.
-
Hi,
ah nun wird es etwas klarer. Ich teste das mal und melde mich nochmal sobald ich noch fragen dazu habe. Danke!
-
sieht dann so aus
-
@JeGr said in Problem / Verständisfrage bezüglich VLANs und Regelwerk - SG-3100:
pass udp from <vlan_net> to <this_firewall> port 53 (DNS)
pass udp from <vlan_net> to <this_firewall> port 123 (NTP)
block any from <vlan_net> to RFC1918 (letzteres ist ein Alias mit 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
pass any from <vlan_net> to anyHi,
ich habe diese Regeln so übernommen das funktioniert pirma :). Ist zwar etwas aufwändig so viele regeln zu pflegen aber doch recht übersichtlich und gut verständlich. Zumindest wenn man das Grundprinzip von pfsense mal verstanden hat.
-
Wir gesagt, die letzten beiden Regeln kann man zusammenfassen.
-
@bahsig said in Problem / Verständisfrage bezüglich VLANs und Regelwerk - SG-3100:
Wir gesagt, die letzten beiden Regeln kann man zusammenfassen.
Führt häufig zu Verwechslung und irritiert viele weil das ! (nicht) gerne übersehen wird. Außerdem hatten wir es schon häufiger, dass ! Regeln nicht so funktionieren wie manch einer denkt. Würde ich der Einfachheit vermeiden.
Ist zwar etwas aufwändig so viele regeln zu pflegen aber doch recht übersichtlich und gut verständlich.
Also wenn 4(!) Regeln für dich schon viel sind, solltest du das mit der Firewall vielleicht nochmal überdenken... wir verwalten hier 4-hundert(!) Regeln auf einem Interface bei großen Kisten. Und sicher könnte man da die ein oder andere zusammenfassen, allerdings sind da viele automatisch erzeugte weil NAT Regeln drin. Hat also Methode ;)
-
Hi,
das bezog sich nicht auf die 4 Regeln. Ich habe natürlich wesentlich mehr. Es müssen halt recht viele Regeln erstellt werden. Ich kenne das aus Vergangenheit anders...allerdings auch andere Firewall von daher alles gut :)
-
War auch spaßig gemeint ;)
Und nicht vergessen, dass man auch Separatoren einfügen kann (4 Farben, beliebiger Text) um das entsprechend zu organisieren und besser verständlich zu machen