Pfsense - rules: Funktion von LAN net

Danke Euch.

@aqui: Sorry, dachte, das ist klar: die .2.153 ist natürlich nicht das Gateway, sondern der interne, also im LAN stehende Fileserver. Die .10.151 ist der Webserver. Hätte ich schreiben sollen. Lass mich gern wissen, wenn noch weitere Infos fehlen. Die Firewall hat sonst aber keine Feinheiten. Ein paar Ports nach außen für die Server. Keine statischen Routen, Squid, Snort und PfBlocker. Nichts, was mich in die Nähe der Fragestellung bringt.

@Pjordorf: Habe eine Weile nachgedacht, ob Deine Antwort bedeuten könnte, dass die pfsense die .2.153 aus dem .10-Netz an das Gateway übergibt, weil dessen Adresse von "LAN net" nicht abgedeckt ist. Das erschiene mir aber seltsam, da ich beim Test ja ausdrücklich die .2.153 (also den Fileserver) adressiere. Auch andere Anfragen ins .2er-Netz kamen bei der in der Frage beschriebenen Konfiguration durch. Das Gateway für das 10er Netz wäre ja auch .10.1 und nicht .2.1, also selbst wenn Traffic an .2.1 durchgereicht werden würde, dürfte er nicht nach .2.153 weiter gehen, oder?

Die pfsense-Doku entspricht der von Dir zitierten reddit-Aussage (der Link gibt diese nicht wieder, s.u.) nicht. Netgate: Interface net = "specify the subnet for that interface exactly"

Dennoch hab ich hier noch einen Thread gefunden, der das gleiche Problem festgestellt zu haben scheint. Dort befindet sich am Ende auch Dein Zitat, allerdings unbelegt:

Does 'LAN net' not include 'LAN address'?

Bei OpenSense, das ja immerhin ein Fork ist, wird die Funktion auch auf das gesamte Subnet bezogen:

Or, in short: the $interface net = the network defined by the $interface's network mask

Ebenso auch im Netgate-Forum:

Regarding "LAN address" vs "LAN Net", the first represents the IP address that pfSense has in that subnet. The last is the entire subnet (all clients on the subnet of the interface, including pfsense itself).

Muss ja aber auch nicht richtig sein, was da so steht.
Wenn LAN net so nicht funktioniert, ist es eben so, aber seht Ihr eine technische Erklärung dafür, warum Netgate das so gemacht hat?

Die "!LAN net" Rule ist die einzige Regel auf dem .10er Interface (DMZ). Dem Zweck der DMZ folgend, wird m.E. auch nicht mehr gebraucht.

Hm, ich hatte gehofft keinen Bug gefunden zu haben OK, die Regel ist natürlich ein bisschen hinten rum. Deine Aussage bestätigt mich aber, dass sie logisch funktionieren müsste. Ich teste sie mal anders herum mit einer "Block Lan net Rule" und einer "Allow any destination" dahinter. Das müsste meiner ein-Regel-Lösung entsprechen. Da kann ich auch gleich sehen, ob "Lan net" dann auch das Gateway blockiert. Am Ende werde das aber nochmal sauberer lösen, damit es auch sicher bleibt, wenn weitere Interfaces hinzukommen.

Ich lass den Thread noch ein bisschen offen und versuche, das als Bug zu melden. Vielleicht findet sich bei Netgate ja noch jemand, der das erläutern kann. Danke erst einmal, es ist immer eine Freude, von Dir zu lesen.

Danke! Das ist sehr nett von Dir, dass Du das getestet hast. Hätte mich auch gewundert, wenn so ein tolles Stück wie die pfsense an so etwas scheitert.

Hast Du irgendeine Idee, woran es liegen könnte, dass es bei mir nicht korrekt läuft? In der DMZ habe ich nur die eine Regel und im LAN habe ich gerade mal alle Regeln abgeschaltet außer der Anti-Lockout und der Default Lan to any - rule. Dennoch voller Ping von DMZ zu LAN (und zwar sowohl von virtuellen Maschinen auf virtuelle und/oder echte, als auch von echten Maschinen auf echte/virtuelle.

Die pfsense läuft selbst virtuell auf nem Windows-Host unter virtualbox. Kann ich hier irgendwas verdreht haben?

Nochmals Danke für den Test. Ich habe auch einen gemacht, ich hatte noch einen älteren Klon. Den aktiviert und dort blockierte die Regel korrekt. Also gesucht, was anders war - und das waren nur ein paar Packages.

Die Regeln waren absolut ok, war auch überhaupt nichts besonderes dabei. Paar Serverfreigaben im WAN, paar Blocks im LAN, sonst Standard. Dann hab ich angefangen die Packages zu deinstallieren und den Ping von DMZ ins LAN dabei beobachtet. Und siehe da, als ich pfBlockerNG deinstalliert habe, bekam ich plötzlich keinen Ping mehr ins LAN (= alles gut). Wahrscheinlich habe ich dort irgendwas falsch konfiguriert - obgleich mir gar nicht klar ist, wie ich damit eine Regelumgehung provozieren kann. Bei der Deinstallation meldete die pfsense auch das Folgende:


Also dort lief irgendwas beim Routing schief, das hat die Regel ausgehebelt. Ohne pfBlockerNG wird auch nach Neustart sauber geblockt. Dann werde ich mich mal auf die Suche machen, was da in pfBlockerNG falsch zu machen war. Schon seltsam, dass pfBlockerNG sich auf Regeln in der DMZ auswirkt, aber es wird sich finden lassen.

Ich lass den Thread noch einen Tag offen, falls noch jemand was anmerken möchte, dann case closed

Danke Icer00, gut gesehen, aber leider am Thema vorbei

Nachtrag:
Neuinstallation der Packages hat die Funktion der pfsense wieder hergestellt. Die Regel funktioniert nun auch wieder trotz Vorhandensein von pfBlockerNG. Offenbar hatte sich dieses im Rahmen des letzten Updates der pfsense verknotet.

Das das allerdings solche Auswirkungen haben kann...

Allerdings kommt auch beim Boot noch

And here, we are:


forum.netgate.com/topic/95407/pfblockerng-dnsbl-virtual-ip-breaks-the-firewall-rules-lan-net