PfSense nach Änderung von "Block private networks and loopback addresses" nicht mehr erreichbar
Ich habe an meiner pfSense am entfernten Standort in den WAN-Einstellungen den Haken bei "Block private networks and loopback addresses" gelöscht.
Nach dem Bestätigen war die Benutzeroberfläche der pfSense nicht mehr über HTTPS (öffentliche IP Adresse) erreichbar (Ping antwortet nicht). Auch der VPN-Tunnel war down.
Hat die Veränderung damit zu tun oder hat sich die pfSense einach nur aufgehängt?
Ich habe Probleme dieser Art schon einige Male gehabt und möchte daher die pfSense über einen Rechner im lokalen Netzwerk steuern können, der von außen über Remote-Control verbunden ist.
Wenn die am VDSL hängende pfSense aufgrund von falscher Konfiguration, VDSL-Ausfall oder Stromausfall nicht mehr von außen zu erreichen ist, soll das Netzwerk über LTE erreichbar sein. Dies würde ich mit einem kleinen "Schnellstart-Router"/LTE von Huawei/Telekom realisieren. Ich habe dazu eine minimale Linux-Installation mit Pepermint auf einem IGEL H710C aufgesezt und AnyDesk installiert.
Zusätzlich überlege ich ich, die pfSense über eine IP-Steckdose aus- und einschalten zu können, sollte diese hängen. Wobei das wohl bei einer guten Konfiguration eigentlich nie der Fall werden sollte.
Für jegliche Tipps in diese Richtung wäre ich dankbar.
Vielen Dank!
Nach dem Bestätigen war die Benutzeroberfläche der pfSense nicht mehr über HTTPS (öffentliche IP Adresse) erreichbar (Ping antwortet nicht). Auch der VPN-Tunnel war down.
Hat die Veränderung damit zu tun oder hat sich die pfSense einach nur aufgehängt?
Ich habe Probleme dieser Art schon einige Male gehabt und möchte daher die pfSense über einen Rechner im lokalen Netzwerk steuern können, der von außen über Remote-Control verbunden ist.
Wenn die am VDSL hängende pfSense aufgrund von falscher Konfiguration, VDSL-Ausfall oder Stromausfall nicht mehr von außen zu erreichen ist, soll das Netzwerk über LTE erreichbar sein. Dies würde ich mit einem kleinen "Schnellstart-Router"/LTE von Huawei/Telekom realisieren. Ich habe dazu eine minimale Linux-Installation mit Pepermint auf einem IGEL H710C aufgesezt und AnyDesk installiert.
Zusätzlich überlege ich ich, die pfSense über eine IP-Steckdose aus- und einschalten zu können, sollte diese hängen. Wobei das wohl bei einer guten Konfiguration eigentlich nie der Fall werden sollte.
Für jegliche Tipps in diese Richtung wäre ich dankbar.
Vielen Dank!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1421103682
Url: https://administrator.de/forum/pfsense-nach-aenderung-von-block-private-networks-and-loopback-addresses-nicht-mehr-erreichbar-1421103682.html
Ausgedruckt am: 09.04.2025 um 22:04 Uhr
6 Kommentare
Neuester Kommentar

Ich habe an meiner pfSense am entfernten Standort in den WAN-Einstellungen den Haken bei "Block private networks and loopback addresses" gelöscht.
OK, eigentlich eine Einstellung die man nicht jeden Tag neu setzt sondern einmal beim First-Setup.Nach dem Bestätigen war die Benutzeroberfläche der pfSense nicht mehr über HTTPS (öffentliche IP Adresse) erreichbar (Ping antwortet nicht). Auch der VPN-Tunnel war down.
Da hat die pfSense wohl das Interface resettet oder einen Dienst neu gestartet.Hat die Veränderung damit zu tun oder hat sich die pfSense einach nur aufgehängt?
Schau halt mal in deine Logs, statt zu raten.Ich habe Probleme dieser Art schon einige Male gehabt und möchte daher die pfSense über Remote-Controle steuern. Wenn die am VDSL hängende pfSense aus was für Gründen (Konfiguration, VDSL-Ausfall, Stromausfall) nicht zu erreichen ist, soll das Netzwerk über LTE erreichbar sein. Dies könnte ich mit einem kleinen LTE-Router (Huawei) von der Telekom realisieren.
Eine Backup-Leitung in der Hinterhand zu haben ist immer eine gute Idee wenn man auf unerwartete Fehler vorbereitet sein will. Ansonsten gilt die Devise: Einstellungen vorher zur Sicherheit in einer VM mit ähnlichem Setup testen, oder Einstellung via Konsole triggern und als Fallback die Einstellung automatisch nach 15 Minuten Rückgängig machen, sollte die Einstellung einen Einfluss auf die Erreichbarkeit gehabt haben. Kommt man innerhalb dieser Zeit wieder rein, kann man diesen automatischen Timer ja vorzeitig abbrechen.
Ich wollte gerne vorher wissen, falls diese Einstellung generell dazu führt, daß die pfSense dann gar nicht zu erreichen ist, weshalb das so ist.
Naja es ist ja erst mal eine Interface-Einstellung die beim anschließenden "Apply" ein Restart des Interfaces auslöst und die Firewall-Regel für die RFC-Netze entfernt, somit auch bestehende Verbindungen über WAN kappt wozu auch VPN Verbindungen gehören (man sägt eben kurzzeitig den Ast ab auf dem man sitzt). Das die pfSense dann danach nicht mehr erreichbar ist und du keine Verbindung mehr per VPN herstellen kannst, ist nicht normal, was das aber letztendlich ausgelöst hat wird dir dein Log-Studium dann sicher verraten Vielleicht hat sie beim Restart des WAN eine neue IP-Adresse bekommen und der DynDNS-Dienst hat sie nicht aktualisiert so dass du jetzt mit falschen DNS-Informationen versuchst sie zu erreichen. So ganz ohne weitere Config-Info ist das hier verständlicherweise Glaskugel raten...

Zitat von @vafk18:
Damit hast Du vermutlich Recht, denn ich habe mir die letzte öffentliche IP aufgeschrieben, bevor ich "apply" bestätigt habe.
Hä warum machst du das manuell?? Nutze doch Dynamic-DNS ... Frage wäre dann auch wie du dein VPN so konfiguriert hast das es auch immer zuverlässig connecten kann wenn du kein Dynamic DNS verwendest und auch keine feste IP? ... Lässt du dir die IP immer erst von einer Brieftaube zuschicken? Damit hast Du vermutlich Recht, denn ich habe mir die letzte öffentliche IP aufgeschrieben, bevor ich "apply" bestätigt habe.