[BUG] Bei IP Table Eintrag sperrt Pfsense sämtlichen Internettraffic vom Lan->WA
-
Hallo Jungs,
damit ist mein gesamter Freitag draufgegangen.Ich hatte vor einiger Zeit versucht Whatsapp im Netz zu sperren (was mir nebenbei nicht gelungen ist)
Dazu hatte ich
https://www.whatsapp.com/cidr.txt
oder
http://www.whatsapp.com/cidr.txtals IP Table Alias angelegt.
Nach einen reboot funktionierte dann mein Internet nicht mehr
Ping PC->PFsense ok
Ping Pfsense->google.de ok
Ping PC->google.de fehlgeschlagen.Das ganze lässt sich reproduzieren.
Ist klasse wenn man nach 2 Monaten den Router mal neustartet und dann nichts mehr geht und man nicht mehr weiß wieso ^^Vielleicht ist einer so nett und probiert es einmal bei sich aus.
Ich habe keine Regel anlegen müssen um den Fehler zu produzieren.
Ich benutze Multi Wan Failover, nur nebenbei. -
Evtl. solltest du nach dem Anlegen deines Aliases mal selbigen prüfen. Dieser sollte ja nach Import in eine normale IP / Netz Tabelle umgewandelt sein.
Möglichkeit 1: Die Einträge sind zu viel -> die Tabelle ist zu groß
Möglichkeit 2: Der Importer mag nicht IPv4 und IPv6 Einträge gleichzeitig im gleichen AliasGrüße
-
Hi, danke für deine Antwort.
Leider wird dann unter Diagnostics: Tables gar nichts mehr erstellt.
Wie gesagt mein gesamtes Internet funktioniert dann nicht mehr.
Zu 2 kann ich dir natürlich das nicht sagen, werde ich aber ausprobieren.Nichts destotrotz, sollte eine Fehlereingabe nicht einfach vom GUI akzeptiert werden und die gesammte Firewall zerschießen :). Daher glaube ich sollte man das an diee Entwickler weitergeben.
Wie geschrieben habe ich versucht : http://www.whatsapp.com/cidr.txt zu importieren. Porbiere es doch bitte auch einmal (auf testsytsem oder wenns grade zuhause passt).Grüße und danke
Marv
-
Hi,
okay, habe mit den Spaß erlaubt, die Sache auf meiner Test-VM so einzurichten und deine Behauptung zu überprüfen.
Kann bestätigen:
-
Die Tabelle wird nie geladen
-
Nach einem Reboot keine Verbindung ins Internet möglich
-
und keine Tabellen vorhanden
Wobei "keine Verbindungen" die Folge von keinen Tabellen ist.
Um die IPv6 Einträge rauszuschmeißen habe ich die Tabelle auf einem eigenen Webserver gestellt und siehe da, die Tabelle wird auch ohne Veränderung geladen und die pfSense arbeitet wie sie soll.
Nun den URL der Tabelle noch dreimal umgestellt - immer das gleiche Bild: eigener Server geht, Whatsapp Server geht nicht.Die Schlussfolgerung: die URL table verbietet in der Regel, die sie anwendet, den Zugriff auf sich selbst. Die Tabelle wird dabei vermutlich nicht fertig geladen und das mag offenbar die pfSense nicht.
Die Katze, die sich in den Schwanz beißt.So dachte ich mir das jedenfalls. Dann habe ich weiter getestet, um nach einem Workaround zu suchen:
-
Eine Regel vor die Block-Regel setzen, die den Zugriff auf www.whatsapp.com von der pfSense selbst aus erlaubt > bringt auch nichts.
-
Die Regel auf Source=any und Protocol=any umgestellt > auch nicht.
-
Anstatt Block-Regel in eine Pass-Regel erstellt, die diesen Alias verwendet > gleiches Bild.
Verdammt, das kann doch nicht sein! Jetzt verstehe ich es nicht mehr.
Also offenbar hat die pfSense ein generelles Problem eine IP Tabelle zu laden, die in einer Regel angewandt wird (nur dann wird die Tabelle auch geladen) und welche die Quell-IP der Tabelle selbst enthält.Hier kann man, denke ich, doch von einem Bug sprechen, der behoben werden sollte.
Übrigens: Laut den Release Notes von 2.2 werden IPv6 Bereiche in Aliases nicht unterstützt. Jedenfalls steht da "Warn that IPv6 address ranges are not supported in aliases". Wurden wohl noch nie unterstützt, aber hier kam offenbar die Warnung hinzu. Ob das auch Bereiche in URL tables betrifft? Ich gehe davon aus.
Siehe: https://doc.pfsense.org/index.php/2.2_New_Features_and_Changes#Aliases
Ich habe keine Aussage gefunden, wonach das Problem bei neueren Versionen behoben worden wäre.Okay, die Lösung für dich zumindest für IPv4 könnte nun sein, die Tabelle auf einen anderen Webserver zu synchronisieren und von da in die pfSense zu laden, vorausgesetzt, du hast einen solchen verfügbar.
Oder die Tabelle direkt auf die pfSense zu synchronisieren und von da zu laden. Wie das funktionieren kann, kann ich dir aber auch nicht sagen.
Oder einfach fix als Alias-File anlegen und eben auf die Synchronisation verzichten.Grüße
-
-
WOW, danke für deine Mühen!
Ja dann ist ja jetzt alles genaustens analysiert :)
Ja ich hatte auch zuerst meine Regeln deaktiviert. Selbst das hilft nichts. Man muss die Regeln komplett löschen.
Die Liste von wo anders laden, habe ich nicht probiert - werde ich aber heute nach der Arbeit mal testen.Danke dir nochmal - und vielleicht ließt ja hier ein Entwickler mit :)
-
Die Sache möchte ich noch mit einer anderen, eigenen Liste testen. Wenn da das Verhalten gleich ist und auch alle Tabellen weg sind, ist sie reif für einen Bug-Report.
-
@virago Wenn ich dich richtig verstanden habe, geht es aber mit einer Liste, die nur v4 Adressen enthält aber korrekt? Ist dann das Problem nicht wirklich nur darin begründet, dass in der whatsapp Liste eben noch v6 Adressen enthalten sind? Oder habe ich was an deinem Test übersehen?
-
@virago Wenn ich dich richtig verstanden habe, geht es aber mit einer Liste, die nur v4 Adressen enthält aber korrekt? Ist dann das Problem nicht wirklich nur darin begründet, dass in der whatsapp Liste eben noch v6 Adressen enthalten sind? Oder habe ich was an deinem Test übersehen?
Ich gehe davon aus das er auch die Liste mit den IPV6 Adressen (also orginal) auf den Webserver geladen hat und die Liste dann trotzdem laden konnte :)
- So oder so, sollte eine Funktion die übers Gui benutzt werden kann nicht so so einen Fehler führen dürfen. Pfsense sollte die Tabelle dann überspringen oder so.
-
Meine Aussage war vorhin, dass die Liste, wenn vom whatsapp Server geladen und in einer Regel angewandt, die pfSense blockiert.
Wenn ich die Liste hingegen auf meinem Webserver stelle, wird sie problemlos geladen.Meine Annahme war, dass die pfSense ein Problem damit hat, weil der Host, von welchem sie geladen werden soll, selbst in der Liste steht.
Um hier den Gegentest anzutreten, habe ich nun das Netz meines Webservers zur Liste hinzugefügt. Laut meiner Annahme müsste die Sense ja dann auch crashen. Tut sie aber nicht.
Die IPv6 Einträge sind nach wie vor in der Tabelle und werden auch in der pfSense GUI Diagnostic > Tables angezeigt, ebenso das Netz meines Webservers.
So, nun habe ich überhaupt keinen Dunst, woran das liegen kann.Die Verwendung des Alias in einer Firewall-Regel ist übrigens gar nicht nötig, um die Tabelle zu laden. Das tut aber auch nichts zur Sache.
Ich habe die Liste mit dem Webbrowser vom whatsapp Server auf meinen Webserver runtergezogen, dann ebenso mit wget, um sicherzugehen, dass der Browser nicht etwas am Datenformat ändert - das macht keinen Unterschied - funktioniert immer problemlos.
Ich habe auch den unverschlüsselten URL vom whatsapp Server in der pfSense verwendet, um etwaige TLS Inkompatibilitäten auszuschließen - gleicher Effekt, die pfSense blockiert.
Auf meinem Webserver greife ich zudem auch verschlüsselt zu.Jetzt bin ich mit meiner Weisheit absolut am Ende und komme zu dem wagen Schluss, die Liste bring die pfSnense zum Crashen, wenn sie vom whatsapp Server gezogen wird, funktioniert aber von sie von einem anderen Server gezogen wird. Warum auch immer. >:(
Dummerweise ist auch im System-Log nichts von dem Problem zu finden. -
Was passiert denn, wenn man eine Liste anlegt die es gar nicht gibt?
Also einfach eine URL einträgt. Gar nichts? -
Wenn es die von vornherein schon nicht gibt, beschwert sich pfSense beim Anlegen des Alias und er lässt sich nicht speichern. Wenn der Link danach beim Neustart oder Reload tot ist, passiert gar nichts.
-
Meine Annahme war, dass die pfSense ein Problem damit hat, weil der Host, von welchem sie geladen werden soll, selbst in der Liste steht.
Ah sorry das hatte ich verpasst.
OK wirklich merkwürdig… evtl. nächste Woche im Urlaub mal debuggen :) -
Meine Annahme war, dass die pfSense ein Problem damit hat, weil der Host, von welchem sie geladen werden soll, selbst in der Liste steht.
Ah sorry das hatte ich verpasst.
OK wirklich merkwürdig… evtl. nächste Woche im Urlaub mal debuggen :)Was rausgefunden :)?
-
Hi,
2.2.5 brachte hier auch keine Änderung.Ich sehe 2 Möglichkeiten, diese Liste dennoch auf pfSense zu nutzen:
-
Über pfBlockerNG.
Da kannst du am IPv4 bzw. IPv6 Tab IP-Listen angeben und wie bei allen anderen pfBlockerNG Filter diese eingangs-, ausgangs- oder beidseitig sperren oder erlauben, oder einfach nur einen Alias anlegen lassen, den du dann in eigenen Firewall-Regeln verwenden kannst. -
Die Liste mit wget od. dgl. auf einen anderen Webserver synchronisieren und diese von da mithilfe eines Aliases laden.
Mit etwas Scriptinggeschick in BSD sollte man sie auch direkt auf die pfSense ziehen können.
Also, warum nicht einen anderen Weg nehmen, wenn der eine blockiert ist.
-
-
Danke. Hab es jetzt mal mit pfBlockerNG versucht. Mal sehen ob es klappt :)