Outgoing RFC1918 blocken aber 192.168.1.1 zulassen

GreenEyedAndy

@wkn ja genau so hatte ich es! Hat aber halt nicht zuverlässig funktioniert, wie ich schon geschrieben habe.

Bob.Dig

@bob-dig said in Outgoing RFC1918 blocken aber 192.168.1.1 zulassen:

Ich hatte da auch so meine Probleme, ich hab mit trial and error eine Regel erstellt, die als Direction any hat, um auf die vorgelagerte Fritzbox zugreifen zu können.

@viragomann Hast Du zufällig ne Ahnung, warum Direction any sein muss bzw. warum eine floating rule eingehend auf LAN nicht funktioniert? Irgendwie widerspricht das ja dem statefull approach.

wkn

Hast du mal versucht, ein weiteres Interface auf den physikalischen WAN-Port zu legen und dann eine Outbound NAT rule auf dem neuen Interface mit Source dein LAN-Netzwerk und Destination das LAN-Netzwerk der Fritzbox und NAT Address die Interface Address?

Ich mache so etwas Ähnliches, um aus dem LAN auf mein Vigor Modem vor der pfSense zu kommen.

NOCling

Ich komme auf mein Modem indem ich eine Virtuelle IP auf das WAN lege aus dem Bereich in dem sich die Modem IP befindet mit /24.
Dann funktioniert der Zugriff mit der Modem IP.

Dieses Netz ist bei mir 192.168.100.0/24, das darf dann aber auch nicht für VPN usw. verwendet werden.

Also versucht es doch mal mit eine vIP auf dem WAN im passendem Bereich zum gewünschtem Ziel, wenn ihr hier keine RFC 1918 IP erhaltet.

Die Hacken bei Privat und Bogon müssen raus, wenn ihr hinter einer Fritz hängt da ihr hier ja hoffentlich private IPs nutzt um das Transfernetz Fritz - Sense zu bauen.

@Bob.Dig
Das Regelwerk kann so nicht funktionieren, weil du da drüber schon eine Regel hast die auf Destination Fritz mit quick liegt.

Bob.Dig

@nocling said in Outgoing RFC1918 blocken aber 192.168.1.1 zulassen:

Das Regelwerk kann so nicht funktionieren, weil du da drüber schon eine Regel hast die auf Destination Fritz mit quick liegt.

Die ist ja deaktiviert. Mit ihr geht das ja mit any, aber ich frag mich halt, warum es mit der andere nicht geht.

Edit: Hab das Bild noch mal angepasst, nur um alle Klarheiten zu beseitigen.
Das Gezeigte (test) geht nicht und ich würde gerne wissen, warum nicht.

thiasaef

@nocling said in Outgoing RFC1918 blocken aber 192.168.1.1 zulassen:

Die Hacken bei Privat und Bogon müssen raus, wenn ihr hinter einer Fritz hängt da ihr hier ja hoffentlich private IPs nutzt um das Transfernetz Fritz - Sense zu bauen.

Ich hab beide Haken drin und komm wunderbar auf den Speedport vor meiner pfSense.

@nocling said in Outgoing RFC1918 blocken aber 192.168.1.1 zulassen:

Ich komme auf mein Modem indem ich eine Virtuelle IP auf das WAN lege aus dem Bereich in dem sich die Modem IP befindet mit /24.

Ja, aber solche Yogaübungen braucht es doch überhaupt nur dann, wenn auf dem WAN Interface eine öffentliche IP anliegt, was bei einer normalen Routerkaskade (um die es hier geht?) ja nicht der Fall ist.

viragomann

@bob-dig said in Outgoing RFC1918 blocken aber 192.168.1.1 zulassen:

@bob-dig said in Outgoing RFC1918 blocken aber 192.168.1.1 zulassen:

Ich hatte da auch so meine Probleme, ich hab mit trial and error eine Regel erstellt, die als Direction any hat, um auf die vorgelagerte Fritzbox zugreifen zu können.

@viragomann Hast Du zufällig ne Ahnung, warum Direction any sein muss bzw. warum eine floating rule eingehend auf LAN nicht funktioniert? Irgendwie widerspricht das ja dem statefull approach.

Hallo,

wie, wenn du in dieser Regel nur die Direction auf any stellst, funktioniert es, mit in aber nicht?

Das würde ich jetzt nicht verstehen, nachdem das einzige Interface LAN und die Quelle LAN net ist. Von einer Direction out dürfte die Regel ja gar nicht profitieren.

Und die deaktivierte Regel funktioniert?
Die hat ja offenbar auch Direction in, aber Source any.

Was ist das überhaupt für eine Konstellation, Double-NAT oder PPPoE oder DHCP mit public IP am WAN?

Bob.Dig

@viragomann Double-NAT. Die LAN Regel funktioniert gar nicht, also kein Zugriff auf die Fritzbox. Die WAN Regel nur wenn any als Direction ausgewählt ist.

thiasaef

@bob-dig said in Outgoing RFC1918 blocken aber 192.168.1.1 zulassen:

Die WAN Regel nur wenn any als Direction ausgewählt ist.

Bei mir funktioniert das exakt so, wie man es erwarten würde (also unabhängig davon, ob ich 'out' oder 'any' auswähle):

Bob.Dig

@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?

thiasaef

@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.

viragomann

@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.

thiasaef

@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:

Bob.Dig

@viragomann So sehe die states aus, oben mit der WAN Regel, die geht und unten mit der LAN Regel, die nicht geht.

Bob.Dig

@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.

wkn

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.

Bob.Dig

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

@bob-dig die Anleitung sagt:

Firewall rules are processed after NAT rules, so rules in the outbound direction on a WAN can never match a local/private IP address source if outbound NAT is active on that interface.

Bob.Dig

@thiasaef Jo, ist aber bei der LAN Rule nicht der Fall gewesen. Denke daher, die states sind da einfach nachrangig.

viragomann

@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.