Pfsense - rules: Funktion von LAN net

Mitglied: commodity

commodity (Level 1) - Jetzt verbinden

12.01.2021, aktualisiert 22:23 Uhr, 573 Aufrufe, 16 Kommentare

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 - Klicke auf das Bild, um es zu vergrößern

Sieht in der Config also so aus:

conf - Klicke auf das Bild, um es zu vergrößern

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 - Klicke auf das Bild, um es zu vergrößern

Aber Pustekuchen, die DMZ erreicht das LAN:

log - Klicke auf das Bild, um es zu vergrößern

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 - Klicke auf das Bild, um es zu vergrößern

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

Danke für Eure Gedanken!
Mitglied: Pjordorf
12.01.2021, aktualisiert um 23:20 Uhr
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
Bitte warten ..
Mitglied: aqui
13.01.2021 um 09:29 Uhr
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.
Bitte warten ..
Mitglied: commodity
13.01.2021, aktualisiert um 12:26 Uhr
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?
Bitte warten ..
Mitglied: aqui
13.01.2021, aktualisiert um 13:03 Uhr
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.
Bitte warten ..
Mitglied: commodity
13.01.2021 um 15:39 Uhr
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.
Bitte warten ..
Mitglied: aqui
13.01.2021 um 15:58 Uhr
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
Bitte warten ..
Mitglied: aqui
LÖSUNG 15.01.2021 um 19:13 Uhr
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

Regelwerk:

fw1 - Klicke auf das Bild, um es zu vergrößern

Ping Check:

fw2 - Klicke auf das Bild, um es zu vergrößern

Quercheck mit einer ANY Regel als Destination:

fw3 - Klicke auf das Bild, um es zu vergrößern

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

Case closed.
https://administrator.de/faq/32
Bitte warten ..
Mitglied: commodity
17.01.2021 um 00:29 Uhr
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?
Bitte warten ..
Mitglied: lcer00
17.01.2021 um 08:47 Uhr
Hallo,

Ping ist ICMP.

TCP/UDP enthält nicht ICMP.

Ändere Deine Regel in Protocol:ANY

Grüße

lcer
Bitte warten ..
Mitglied: commodity
17.01.2021 um 22:50 Uhr
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 - Klicke auf das Bild, um es zu vergrößern

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
Bitte warten ..
Mitglied: commodity
17.01.2021 um 22:50 Uhr
Danke Icer00, gut gesehen, aber leider am Thema vorbei :-) face-smile
Bitte warten ..
Mitglied: commodity
17.01.2021 um 23:33 Uhr
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 - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: lcer00
18.01.2021 um 07:12 Uhr
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
Bitte warten ..
Mitglied: aqui
18.01.2021 um 10:28 Uhr
Richtig ! Die simpelsten Protokoll Grundlagen sollte man schon kennen wenn man mit Regeln jongliert...! ;-) face-wink
Bitte warten ..
Mitglied: commodity
19.01.2021 um 00:29 Uhr
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.
Bitte warten ..
Heiß diskutierte Inhalte
Windows Server
Lizenzrecht Microsoft HILFE!!!!
gelöst tAmtAm44Vor 17 StundenFrageWindows Server26 Kommentare

Guten Abend liebe Community, ich bin vor kurzen bei uns in der Firma für den Vertrieb unsere MS Lizenzen auserwählt worden. Leider habe ich ...

Netzwerke
Windows 10 - Netzwerk Speedlimit?
alwayshungryVor 1 TagFrageNetzwerke17 Kommentare

Hallo, ich bin noch neu hier und hoffe, dass ihr mir helfen könnt. Gibt es eine Limitierung für Windows 10 bei der Netzwerkgeschwindigkeit? Leider ...

DNS
Domain überkleben
IT-EinsteigerVor 1 TagFrageDNS3 Kommentare

Guten Morgen, Ich habe mir einen WebSpace angemietet. Dieser läuft bspw. über die Domain storage.dienstleister.de. Jetzt ist das kein schöner Name und ich hätte ...

Datenschutz
Ist Microsoft Office 365 grds. nicht DSGVO-konform?
imebroVor 19 StundenFrageDatenschutz29 Kommentare

Hallo, in einem anderen Thread hatte man mir als Alternative zum Analysetool "Tableau" das Programm "PowerBI" empfohlen, welches ich dann auch gekauft habe. Da ...

Festplatten, SSD, Raid
WD RED PRO Festplatte als "Recertified" und "white" gelabelt
gelöst Torsten2010Vor 1 TagFrageFestplatten, SSD, Raid5 Kommentare

Hallo, ich wollte heute die Firmen QNAP Nas mit neuen Festplatten bestücken. Beim Auspacken fiel mir sofort auf, das die Festplatten weiß gelabelt sind ...

Groupware
Anfängerfrage zu Teams, wie kann ich mit einer externen Person chatten?
StefanKittelVor 1 TagFrageGroupware7 Kommentare

Hallo, ich habe mal eine Anfängerfrage zur MS Teams. Ich habe einen M365 Business Basic Account mit meiner Domäne. Ich habe einen User mit ...

Windows 10
Inaccessible boot device bei Windows 10
jensgebkenVor 1 TagFrageWindows 1014 Kommentare

Hallo Gemeinschaft, habe Probleme bei einem Windows 10 Pro PC beim Start - blue screen mit inaccessible boot device habe folgendes probiert - automatische ...

SAN, NAS, DAS
FritzBox NAS - Hochladen von großen Dateien geht nicht
emeriksVor 1 TagFrageSAN, NAS, DAS14 Kommentare

Hi, (Habe die Kategorie "SAN, NAS, DAS" genommen, obwohl nicht 100% zutreffend.) Ich habe am Wochenende versucht bei einem Kumpel in der Ferne eine ...