Outgoing RFC1918 blocken aber 192.168.1.1 zulassen
-
@thiasaef Ich versteh insbesondere nicht, warum die LAN Regel nicht funktioniert. Das ist doch eine ganz normale statefull Regel wie jegliches Websurfing auch. Oder unterbrechen meine anderen Blockierungen auf WAN auch existierende states?
-
@bob-dig da bin ich überfragt, aber genau deshalb käme mir auch nicht in den Sinn, ohne Not solche Verrenkungen mit Floating Regeln zu veranstalten.
-
@bob-dig
Mit der WAN Regel bekommst du natürlich alles auf die FritzBox, jede Quelle. Direction out sollte dafür aber reichen.Die LAN Regel müsste aber nach meinem Verständnis ebenso funktionieren, jedenfalls für das "LAN net".
Einzige Erklärung für mich, dass sie nicht funktioniert, wäre dass eines der drei einschränkenden Parameter nicht zutrifft:
Interface: LAN
Address family: IPv4
Source: LAN net
Aber ich denke, das hast du alles schon dreifach überprüft. -
@viragomann said in Outgoing RFC1918 blocken aber 192.168.1.1 zulassen:
Die LAN Regel müsste aber nach meinem Verständnis ebenso funktionieren
Funktioniert bei mir übrigens auch nicht:
-
@viragomann So sehe die states aus, oben mit der WAN Regel, die geht und unten mit der LAN Regel, die nicht geht.
-
@thiasaef said in Outgoing RFC1918 blocken aber 192.168.1.1 zulassen:
Funktioniert bei mir übrigens auch nicht:
Vermutlich irgendein firewall basic, welches mir nicht bekannt ist.
-
Ich bin ja immer noch der Meinung, die pfSense hinter einem Modem und VOR der Fritzbox im Client-Modus ist der einfachere Setup für dein Netzwerk und verhindert auch Double-NAT usw.
Ist ein oft beschrittener Weg, der auch sehr gut funktioniert und der Fritzbox ihre Funktionalität für WLAN und Telefonie voll erhält. -
Ich hab mal die Probe aufs Exempel gemacht und die ganzen RFC*-Block Rules deaktiviert, damit hat der Zugriff ohne Probleme geklappt, obwohl diese Regeln ja alle unterhalb der besagten Regel standen. D.h. wohl, dass die states da nachrangig sind oder wie immer man das beschreiben sollte.
-
-
@thiasaef Jo, ist aber bei der LAN Rule nicht der Fall gewesen. Denke daher, die states sind da einfach nachrangig.
-
@bob-dig
Wird da eigentlich eine Outbound NAT Regel auf den Traffic angewandt?
Die States würden ja nicht darauf hindeuten, die Tatsache, dass die WAN-Regel funktioniert, eher doch.Ich hatte hier auch schon von 2 Leuten gelesen, dass sie den Zugriff nur mit einer Policy-Routing Regel hinbekommen haben, mit dem Router als Gateway. Den Grund kann ich mir auch nicht erklären.
-
@viragomann Ja, ganz normal, WAN ist das default gateway bei mir mit entsprechendem outbound NAT.
Das Gateway noch mal explizit festgelegt hatte ich auch schon gemacht, nachdem ich es hier gelesen hatte. Hat natürlich keinen Unterschied gemacht (da halt default). -
Na wenn du die Floating Regel mit LAN Int und LAN Netz auf Fritzbox als in definierst geht das zwar, aber da du auf dem WAN Bogon blockst gehts halt nicht mehr zurück.
Setzt du die Regel aber auf WAN, dann lässt du damit diese eine Bogon IP zu und damit hast du hier wieder einen Stete der zustande kommt.
Aber baut ruhig so Umleitungen ein, statt die beiden Hacken bei WAN raus zu nehmen, wenn ihr hier ein RFC1918 Netz verwendet!
Aber dann braucht ihr euch nicht wundern, wenn es dann erst funktioniert, nachdem man das irgendwie dann mit einem Workarround umgangen hat...
-
@nocling said in Outgoing RFC1918 blocken aber 192.168.1.1 zulassen:
Aber baut ruhig so Umleitungen ein
Es geht doch hier um Verbindungen, die aus dem LAN Netz heraus in ein WAN seitiges RFC1918 Netz aufgebaut werden und nicht um den umgekehrten Fall. Welche Rolle soll da bitte der Haken bei
Block private networks and loopback addresses
auf dem WAN Interface spielen?Statt sich mit Floating Regeln ins Knie zu schießen, wäre es vielleicht sinnvoller, bei den Pass Regeln auf den jeweiligen LAN Netzwerken (HERDE, GAST, IOT) einfach mit
Destination = !RFC1918
zu arbeiten und Zugriffe auf 192.168.1.1 nur vom (Management) LAN aus zu erlauben. Ich sag nur KISS.