commodity
Goto Top

Pfsense - rules: Funktion von LAN net

Hallo liebe Netzwerker, ich bin heute auf ein Loch in meiner Firewall gestoßen, dessen Ursache ich nicht recht nachvollziehen kann. Also erklärt mir doch bitte ob/warum ich zu blöd war bzw. was an der Rule-Option "LAN net" ich falsch verstehe.

Mein Setup ist eine kleine pfsense mit physischen Interfaces für WAN, LAN (192.168.2.0) und DMZ (192.168.10.0). In der DMZ stehen u.a. Web- und Mailserver. Diese sollen das Internet erreichen können, natürlich nicht aber das LAN. Da keine weiteren Interfaces bestehen, fand ich, es genügt das LAN auszuschließen, mit der Regel in Rules/DMZ:

rule

Sieht in der Config also so aus:

conf

Ich war der Auffassung, LAN net meint das gesamte Subnet für das LAN und mit der "allow" Regel bei invertierter Destination "LAN net" erlaube ich Zugriff überall hin, aber nicht ins LAN.

So verstehe ich auch die Netgate-Dokumentation

netgate-info

Aber Pustekuchen, die DMZ erreicht das LAN:

log

Was ist hier falsch?

Klar, ich hätte das anders lösen können und habe das auch schon, also bitte keine Lösungen, sondern ich würde gern verstehen, warum "!LAN net" hier nicht greift. Wahrscheinlich ist es ganz einfach und ich stehe nur auf dem Schlauch.

Die alternativ von mir angewendete (und sicher sauberere) Lösung

rule-modworks

funktioniert. Was also ist an "LAN net" hier anders als an 192.168.2.0/24?

Danke für Eure Gedanken!

Content-Key: 639722

Url: https://administrator.de/contentid/639722

Ausgedruckt am: 29.03.2024 um 13:03 Uhr

Mitglied: Pjordorf
Pjordorf 12.01.2021 aktualisiert um 23:20:03 Uhr
Goto Top
Hallo,

Zitat von @commodity:
Ich war der Auffassung, LAN net meint das gesamte Subnet für das LAN
Ohne die Gateway IP. LAN.NET is intended for everything but the gateway. You need to use lan address if you want the Gateway. ES gibt LAN ADDRESS und LAN NET
https://www.reddit.com/r/PFSENSE/comments/jt8be5/whats_the_difference_be ...

Gruß,
Peter
Mitglied: aqui
aqui 13.01.2021 um 09:29:08 Uhr
Goto Top
Würde dann aber bedeuten das die .2.153 die Firewall Interface IP ist. Dann ein typisches Problem weil der TO vergessen hat die Anti Lockout Rule zu deaktivieren.
Wäre etwas komisch denn der TO wird vermutlich nicht solche Adressen mitten im IP Segment als zentrale Gateway IP für die Firewall verwenden. Kundige Netzwerker nehmen bei einem 24er Prefix da immer die .1 oder .254. Leider bleibt hier mal wieder nur raten. face-sad
Es geht ja um eine SSH Session vom Absender .10.151 auf das Ziel .2.153. Wäre also hilfreich wenn man wüsste was sich hinter diesen Hostadressen verbirgt.
Mitglied: commodity
commodity 13.01.2021 aktualisiert um 12:26:56 Uhr
Goto Top
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?
Mitglied: aqui
aqui 13.01.2021 aktualisiert um 13:03:10 Uhr
Goto Top
Dann hast du vermutlich einen Fehler im Regelwerk selber. Ist die "!LAN_net" Rule deine einzige Regel auf dem .2.0er Port der Firewall ??
Wenn ja hast du ggf. hier die Grundregel "Firt match wins !" übersehen sollten wirklich noch weitere Regeln dort definiert sein die in der Reihenfolge VOR der "!LAN_net" Rule stehen und ggf. global TCP 22 erlauben oder andere Teile der IP Range dort in dem der Server liegt.
Dann ergibt das einen positiven Hit im Regelwerk und der gesamte Rest wird NICHT mehr abgearbeitet !
Könnte das ein möglicher Grund sein ?
Ansonsten hast du vermutlich einen Bug gefunden.
Mitglied: commodity
commodity 13.01.2021 um 15:39:25 Uhr
Goto Top
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 face-smile 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.
Mitglied: aqui
aqui 13.01.2021 um 15:58:06 Uhr
Goto Top
OK, die Regel ist natürlich ein bisschen hinten rum.
Nöö, syntaktisch ist sie absolut korrekt und sollte auch so greifen wie gedacht.
Ich checke das hier auch einmal auf einer Labor pfSense... Es bleibt spannend face-wink
Mitglied: aqui
Lösung aqui 15.01.2021 um 19:13:34 Uhr
Goto Top
So, Labor Test gemacht und um das Ergebnis gleich vorweg zu nehmen: Es klappt fehlerlos wie es soll !
Testobjegt ist ein Managed Switch im VLAN 1 mit der IP 172.30.1.100
back-to-topRegelwerk:
fw1
back-to-topPing Check:
fw2
back-to-topQuercheck mit einer ANY Regel als Destination:
fw3

Fazit: Works as designed ! 😉
Bei dir muss also irgendetwas anderes den Ping verhindern.

Case closed.
Wie kann ich einen Beitrag als gelöst markieren?
Mitglied: commodity
commodity 17.01.2021 um 00:29:35 Uhr
Goto Top
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?
Mitglied: lcer00
lcer00 17.01.2021 um 08:47:43 Uhr
Goto Top
Hallo,

Ping ist ICMP.

TCP/UDP enthält nicht ICMP.

Ändere Deine Regel in Protocol:ANY

Grüße

lcer
Mitglied: commodity
commodity 17.01.2021 um 22:50:00 Uhr
Goto Top
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:

pfblockerng

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 face-wink
Mitglied: commodity
commodity 17.01.2021 um 22:50:50 Uhr
Goto Top
Danke Icer00, gut gesehen, aber leider am Thema vorbei face-smile
Mitglied: commodity
commodity 17.01.2021 um 23:33:30 Uhr
Goto Top
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

boot
Mitglied: commodity
commodity 18.01.2021 um 00:03:09 Uhr
Goto Top
Mitglied: lcer00
lcer00 18.01.2021 um 07:12:36 Uhr
Goto Top
Zitat von @commodity:

Danke Icer00, gut gesehen, aber leider am Thema vorbei face-smile

Na ja, wenn Du TCP/UDP Regeln mit ICMP testest, ist das nicht wirklich zielführend.

Grüße

lcer
Mitglied: aqui
aqui 18.01.2021 um 10:28:02 Uhr
Goto Top
Richtig ! Die simpelsten Protokoll Grundlagen sollte man schon kennen wenn man mit Regeln jongliert...! face-wink
Mitglied: commodity
commodity 19.01.2021 um 00:29:24 Uhr
Goto Top
Absolut! Aber das war hier ja nicht das Problem. Das hatte @icer00 nur reingelesen, weil er unseren (für den case völlig bedeutungslosen) Schwenk von ssh auf ping nicht nachvollzogen hat. Wenn es darum gegangen wäre, dass mein Ping nicht durch kam, wäre das seltsame Verhalten der pfsense ja gar nicht aufgefallen face-smile

Danke nochmals für die Unterstützung! Fall gelöst.