Nach Update von 22.01 auf 22.05 Probleme mit Captive Portal
-
@opit-gmbh Der Patch geht wahrscheinlich wegen dem custom Pfad Element nicht? Da steht ja im Gegensatz zu normalen Patchfiles das /opit/... drin, was bei @pipen1976 wahrscheinlich nicht matcht?
-
Das Captive Portal war bis Samstag, also ca. 4 Tage ohne Probleme erreichbar. Von einer Minute auf die andere konnte kein Gerät (Windows, Android und Apple) mehr auf die Portalseite zugreifen. Alle anderen Netze, also Produktiv WLAN, Kassen WLAN usw. funktioniert weiterhin einwandfrei. Da ich am Samstag nicht vor Ort war und im System nachschauen konnte, gab ich das ok für einen Neustart der pfSense (Stecker ziehen). Als die pfSense wieder Online war, funktionierte alles wieder wie vorher. 2 Jahre lief die pfSense einwandfrei, bis zu diesem 22.05 Update. Es gab keinen Hänger und keinen Ausfall. Hat jemand noch irgend eine Idee?
-
@pipen1976 said in Nach Update von 22.01 auf 22.05 Probleme mit Captive Portal:
ls die pfSense wieder Online war, funktionierte alles wieder wie vorher. 2 Jahre lief die pfSense einwandfrei, bis zu diesem 22.05 Update. Es gab keinen Hänger und keinen Ausfall. Hat jemand noch irgend eine Idee?
Das liest sich aber wie das erwähnte Problem in dem Ticket, dass keine Pipes mehr vorhanden sind weil die aus irgendeinem Grund nicht freigegeben werden. Wurde ein Patch denn jetzt angewendet oder nicht?
Ansonsten ist seit 22.05 - jetzt mehrfach beschrieben - das Portal insofern umgebaut, dass der traffic nicht mehr unnötig via ipfw doppelt gefiltert wurde (erst ipfw für portal, dann pf für Rest), sondern jetzt alles über pf geht. Das wurde komplett umgekrempelt, insofern kann(!) es da eben noch zu den beschriebenen Fehlern führen.
Nur damit man jetzt nicht an der falschen Stelle sucht daher obige Frage: irgendein Patch aus den verlinkten Threads/Redmine Issues nun angewendet worden oder nicht? Ansonsten können wir nur mal den Patch von @OpIT-GmbH nochmal ansehen und gegen ein frisches System matchen lassen um ggf. das Problem mit dem Spacing oder den Ordnern zu entfernen damit du den anwenden kannst. Das würde ich mir nochmal ansehen.
Cheers
-
@jegr Also wie bereits geschrieben wird der Patch den du mir oben verlinkt hast ausgefĂĽhrt. Seit dem hat das CP eigentlich ein paar Tage funktioniert.
Beim Patch von @OpIT-GmbH bekomme ich eine Fehlermeldung, siehe Post oben. -
Komisch, bei mir funktioniert das so, habs eben noch mal getestet. Du kannst ja auch die Datei selber editieren, du musst nicht zwingend die Patch Funktion verwenden.
Was steht da wenn du bei dem Fehler auf Detail klickst?
-
-
Hast du bei der Datei /usr/local/captiveportal/index.php bereits was geändert? Wenn er nicht findet was er in der Zeile XXX sucht, gehts das natürlich nicht.
Diagnostics > Edit File > /usr/local/captiveportal/index.php
Suche nach
$pipeno = captiveportal_get_next_dn_ruleno('auth', 2000, 64500, true);
Ersetze mit
$pipeno = captiveportal_get_next_dn_ruleno('auth', 2000, 64500, false);
Also anstatt "true" auf "false". Mehr macht der Patch nicht....
-
@opit-gmbh Oke, also der Patch ersetzt lediglich in der /usr/local/captiveportal/index.php in der Zeile $pipeno = captiveportal_get_next_dn_ruleno('auth', 2000, 64500, true); true durch false? Wenn ich die Zeile manuell ändere dann benötige ich den Patch nicht, oder? Sehe ich das richtig?
-
Ja genau, das sollte so richtig sein...
-
@opit-gmbh Ja super, vielen Dank. Jetzt bleibt nur noch abwarten.....
-
Der Patch ist halt fĂĽr den Limiter Bug, also wenn du im Captive Portal pro User die Geschwindigkeit Limitierst. Ohne dem Patch siehst du in Diagnostics > Limiter Info nur einen Eintrag (auch wenn mehrere Eingeloggt sind). Mit dem Patch ist dann dort fĂĽr jeden User ein Eintrag....
-
@opit-gmbh Welchen Patch meinst du jetzt?
-
Den was ich dir geschrieben habe...
-
@opit-gmbh Der funktioniert bei mir nicht. Wenn ich einen neuen Patch erstelle, Deinen Code eintrage, bekomme ich kein apply, sondern erhalte beim debug die Fehler.
Diesen Code gebe ich ein:
diff --git a/opit/usr/local/captiveportal/index.php b/opit/usr/local/captiveportal/index.php
--- a/opit/usr/local/captiveportal/index.php
+++ b/opit/usr/local/captiveportal/index.php
@@ -249,7 +249,7 @@
$context = 'first';
}$pipeno = captiveportal_get_next_dn_ruleno('auth', 2000, 64500, true);
$pipeno = captiveportal_get_next_dn_ruleno('auth', 2000, 64500, false);
/* if the pool is empty, return appropriate message and exit */
if (is_null($pipeno)) {
$replymsg = gettext("System reached maximum login capacity");Was mir da auffällt a/opit und b/opit gibt es bei mir nicht. Vielleicht findet er da den Pfad nicht.
-
du hast den Patch ja bereits manuell eingetragen, so wie oben beschrieben.... Wenn du bereits vorher was schon an der index.php gemacht / angepasst hast, klappt das auch nicht mit dem Patch, da er dann in der Zeile wo er sucht, das eben nicht findet. Ă„ndere das ganze mal manuell, dann testest du ob dir das ĂĽberhaupt was bringt / hilft...
-
Mein Chef hat mir gerade berichtet, das am Wochenende wieder keine Portal Anmeldung funktionierte. Erst nach Neustart pfSense, also Strom weg gings wieder.
-
@pipen1976
Komisch, dieses Problem haben wir nicht (mehrere Netgates). Alle Pakete sind UpToDate? Sonnst fällt mir da nix mehr ein... -
@opit-gmbh Ich verstehe es auch nicht. Mittlerweile habe ich eine Backup Netgate (High Av. - Carp) mit der 22.01 FW am Laufen. Mal schauen ob es mit dieser wieder Problemlos funktioniert.
-
Ich habe mir das hier mal alles durchgelesen und mir
sind da einige Punkte zu aufgefallen, muss nicht die
Lösung sein, kann aber eventuell einiges erklären
oder verdeutlichen und dem einen oder anderen helfen.Quelle: Troubleshooting Captive Portal
-
Anmeldung am Captive Portal
For local users, if the option to require the Captive
Portal login privilege is enabled, ensure the users
have the privilege directly or are members of a
group with the privilege. -
HTTP/HTTPS
The request must be to an HTTP site in order for
the portal to redirect the client. If HTTPS is enabled
for the portal, this may still work but it depends upon
the client browser or operating system automatic
portal detection to work. Many modern browsers
and operating systems detect portals now which
makes this less of an issue. -
IPv6 basierende Probleme
Captive Portal does not currently support IPv6, so
IPv6 traffic is not able to traverse the portal interface.
If the interface has IPv6 configured and the client
attempts to use it, it may encounter network timeouts. -
Probleme mit Apple Geräte
There have also been reports that on older version of
macOS, a Mac would refuse to load any HTTPS sites,
including an HTTPS portal, until it could load a CRL
and OSCP URL for the certificate. This has been fixed
in current versions of OS X.
Some users have had to add www.apple.com to their
allowed hostnames so that Apple’s call to their test page
succeeds.- Captive Portal Firewallregeln
On pfSense Plus software version 22.05 or CE version
2.7.0 or later, Captive Portal uses pf features for L2
ether processing under the hood. When having issues
with the captive portal, it is possible to inspect the
rules for debugging purposes.
To see rules for Captive Portal look in /tmp/rules.debug at the multiple sections starting with a comment # Captive Portal.
Ich hoffe auch wenn es auf englisch ist das der Eine oder Andere von Euch hier etwas findet das sein Problem besser
beschreibt oder erklärt, wenn er es damit auch noch lösen kann ist das natürlich noch besser. -
