Fragen / Anmerkungen zu 1.2-release
-
Hallo
Zuerst einmal herzlichen Dank an das gesamte pfSense Team für ihre Arbeit und das entstandene 1.2er Release ;D.
Ich habe ein Update von 1.2-RC2 auf 1.2-release durchgeführt. Das System läuft auf einem Tyan S3095 Board mit drei Network Interfaces (1x WAN, auf die beiden anderen sind ca. 20 Vlans aufgeteilt). Dabei sind mir folgende Punkte aufgefallen:
1. Das Update wurde zunächst über das Webinterface vorgenommen. Anscheinend wurde der non-smp Kernel installiert, da auch nur eine single core CPU eingebaut ist. Anschliessend startete das System mit mehrfachen Error Messages: "fxp0: device timeout". Dementsprechend standen nach dem Start auch keine LAN und OPT Interfaces zur Verfügung. Beim Boot des Kernels ohne ACPI Unterstützung lief alles glatt.
2. Nun sollten einige Vlans gelöscht sowie andere neu angelegt werden. Die ersten drei Vlans ließen sich per Webinterface löschen, doch das Löschen von OPT14 resultierte in folgender Error Message: "XML error: OPTXXXX at line 628 cannot occur more than once".
Das fatale dabei war, daß die Web-GUI danach nicht mehr ansprechbar war und nur noch diese Error Message angezeigt wurde. Der gleiche Fehler wurde auch bei jeglicher Aktion in der Console angezeigt.3. Da nun scheinbar kein konsistenter Zustand mehr vorhanden war und auch kein Reset möglich war, wurde pfSense 1.2-release neu installiert, diesmal mit dem smp-Kernel. Nun startete das System auch wieder mit ACPI Unterstützung ohne den timeout error. Die vor der Update-Orgie gesicherte Config ;) wurde zurückgespielt. Beim erneuten Löschversuch von OPT14 kam es zu der gleichen Situation wie in Punkt 2. Es half also nur, die zu löschenden Vlans direkt aus der config.xml herauszunehmen und diese in ein sauber installiertes Setup mit smp-Kernel einzuspielen.
4. Anschliessend konnte man über die Web-GUI problemlos neue Vlans anlegen. Beim Start fällt auf, daß das System ca. 2min beim Punkt "Syncing system time before startup" verweilt. Was macht das System so lange?
5. In der neuen Version fiel auf, daß die Status Seiten nicht mehr automatisch aktualisieren. Ist dafür jetzt das Paket "Dashboard" nötig?
6. Im Firewall Log fallen jetzt regelmäßige Drop Messages von diversen Windows Rechnern und Samba Servern auf, die als Ziel die Broadcast Adresse des jeweiligen Subnets haben. Das war mit dem gleichen Ruleset unter 1.2-RC2 nicht der Fall. Was hat sich da zur 1.2-release geändert?
7. Bei 1.2-RC2 hatten alle internen Interfaces standardmäßig Zugriff auf den openNTPD in pfSense (Interface IP, Port 123 UDP). In 1.2-release muß der Zugriff darauf nun für jedes Subnet per Regel freigegeben werden. War dies in 1.2-RC2 so gewünscht, daß der Zugriff generell möglich war?
Die in Punkt 1-3 genannten Auffälligkeiten waren zwar ärgerlich bzw. haben einiges an Zeit gekostet aber vielleicht lässt sich durch die Error Message der Fehler erklären bzw. in zukünftigen Versionen solche Fälle abfangen. Wichtig ist, daß das System durch das manuelle Editieren der config.xml wieder normal läuft ;).
Vielleicht kann jemand etwas zu den Punkten 4-7 sagen, da sich hier das Verhalten gegenüber 1.2-RC2 geändert hat und ich gerne wüsste, ob das alles seine Richtigkeit hat.
PS: Das Web-GUI wird bei 20 Vlans leider ziemlich auseinander gerissen. Ich erinnere mich an ein Topic, daß deshalb in Zukunft eine andere Darstellung (per Dropdown Box o.ä.) gewählt werden sollte. Weiß jemand, ob dies für 1.3 geplant ist?
-
zu 1. Wenn Du das update hochlädst ist da eine kleine Dropdownbox, welche Kernelversion Du installieren möchtest (SMP, uniprocessor, developer, embedded). Das ist noch nicht lange so, hast Du vielleicht nur übersehen im Eifer des Gefechts ;)
zu 2. Das klingt nach einem Bug. Ich werde Die Fehlermeldung mal zum Diskutieren in die Dev-liste stellen. Danke.
zu 5. Das wurde mit Absicht herausgenommen, weil es lästig war, daß, wenn man gerade im log nach was sucht, die Seite wieder neu geladen wurde. Das wird auch so bleiben. Das Dashboard ist nicht ganz vergleichbar bzw. bietet nicht alle Diagnostics- und Statusseiten, ist aber dafür komplett dynamisch.
zu 6. Die Broadcastdrops habe ich eigentlich schon immer gesehen. Da hat sich meines Wissens nach nichts geändert.
zu 7. Ich weiß jetzt nicht, ob sich da was geändert hat, aber ich begrüße das neue Verhalten. Anders wäre es ja nicht möglich z.B. auf einem OPT-WAN oder einer DMZ diese Verbindungen zu blocken.
zu P.S. Stimmt, das wurde schon mal diskutiert. Ich stoße das Thema noch mal im Dev-Channel an. Vielleicht können wir ja da noch was verbessern bis die 1.3 rauskommt.
-
Danke für die ausführliche Antwort.
zu 5. Ich meinte eigentlich das Paket Dyntables, welches laut der Beschreibung den alten Effekt wieder herstellt, nur eben auf Ajax Basis. Ich habe das Paket mal in einer virtuellen pfSense installiert, nur aktualisiert leider immer noch nichts automatisch und ich konnte auch keinen Verweis zu eventuellen Einstellungen des Paketes in den Menus finden.
zu 6. Die Broadcastdrops sind mir bei 1.2-RC2 niemals aufgefallen und ich hatte während diverser Tests und Versuche oft das Log mitlaufen. Wie werde ich diese Log Einträge wieder los? Müsste ich in jedem Subnet, wo Broadcasts gesendet werden, eine Regel erstellen, daß Broadcastdrops nicht geloggt werden sollen?
zu. 7. Ich begrüße das neue Verhalten ebenso, in 1.2-RC2 war dadurch die Default Policy "Drop All" ja nicht ganz konsequent umgesetzt.
-
zu 5. Das Dyntables-Paket wurde nie richtig fertiggestellt und umfaßt auch nicht alle Guiseiten. Da der entsprechende Entwickler nicht mehr bei pfSense mitarbeitet sollten wir das vielleicht besser entfernen. Werde ich klären.
zu 6. Schreibe Dir einfach eine Regel am Ende Deiner Firewallregeln unter dem entsprechenden Tab:
…
(normale Regeln)
...
Block protocol any, source any, destination <broadcastadresse>, gateway default (Regel ohne logging Option)Dadurch wird der Traffic geblockt, aber da kein Logging stattfindet erscheint nichts mehr in den Logs.
Auf die gleiche Art und Weise kannst Du auch andere "normale" Ereignisse aus den Logs ausblenden, die Du womöglich nicht sehen möchtest.</broadcastadresse>
-
zu 5. Das Dyntables-Paket wurde nie richtig fertiggestellt und umfaßt auch nicht alle Guiseiten. Da der entsprechende Entwickler nicht mehr bei pfSense mitarbeitet sollten wir das vielleicht besser entfernen. Werde ich klären.
das funktioniert sowieso nur für die DHCP Lease Seite, mein letzter Test ist da aber auch schon Monate her. Da es hierfür offensichtlich keine Weiterführung gibt, macht das Paket so m.E. nicht viel Sinn.
-
zu 2): "XML error: OPTXXXX at line 628 cannot occur more than once"
Wann wird denn in der config.xml ein Interface mit dem Namen optXXXX oder optxxxx erzeugt?
Bei mir trat das Problem ebenfalls auf als ich mit VLANs herumspielte (Anlegen und Löschen)
In der .XML waren dann zwei Einträge vorhanden, einmal: optxxxx und einmal optXXXX.
Nach händischem Löschen und Zurückspielen/reboot (via WinSCP, das funktioniert dann noch), waren GUI und Konsole wieder erreichbar.
