Problem Captive Portal auf pfSense - mal wieder . .
Ein freundliches Hallo an dieses sehr gute Forum!
Ich hatte bis vor kurzem eine pfSense auf einem etwas betagten ALIX zu laufen. Nach einem Update verweigerte die SD-Card den Dienst.
Die Konfiguration ist so, dass der WAN-Port --> an einer FB hängt (hier per DHCP), am LAN-Port ("Arbeitsname" CONFIG) --> der Admin-PC via LAN und statischer IP bei Bedarf verbunden wird. Am optionalen Port ("APINTERN") --> hängt ein WLAN-AP; Port hat statische IP und hier ist DHCP aktiviert. Die IP-Adressen sind beispielhaft, die FB ist zum Test auf Standard-IP eingestellt. HTTPS-Login am CP ist nicht aktiviert.
Mit einer neuen Card und der Anleitung von "aqui" war das Teil schnell wieder aufgesetzt (Version 2.3.5-Release-p2). Haken ist, dass kein Backup der Einstellungen mehr verfügbar ist (Kein Backup - kein Erbarmen - ich weiss!). Also die Einstellungen des Captive Portals wieder (nach Anleitung) "regeneriert". Mit einer "Alles offen"-Firewall Regel läuft zum Test die Verbindung zum Internet (Notebook via WLAN an APINTERN). Nach Aktivierung des Captive Portals (vorher User, Gruppe und Zuweisung des Portal-Logins auf den User eingerichtet) ist keine Verbindung zum Internet mehr möglich.
Verwunderlich ist, dass die Portalseite (getestet mit Standardseite und eigener login.html) nicht angezeigt wird. Bei direktem Aufruf einer URL kommt ein Timeout. Wenn die pfSense-IP (lokal) mit Port 8000/ 8002 aufgerufen wird erscheint eine weiße Seite. Im Firewall-Log ist kein Eintrag zu finden. Auch die Anlage einer FW-Rule (siehe Screenshot) bringt keine Lösung.
Wo könnte mein Fehler liegen und welche Informationen werden noch benötigt? Im Folgenden noch ein paar Einstellungen im Screenshot.
Ich würde mich über eine paar "Denkanstöße" freuen.
Gruss Frank
Ich hatte bis vor kurzem eine pfSense auf einem etwas betagten ALIX zu laufen. Nach einem Update verweigerte die SD-Card den Dienst.
Die Konfiguration ist so, dass der WAN-Port --> an einer FB hängt (hier per DHCP), am LAN-Port ("Arbeitsname" CONFIG) --> der Admin-PC via LAN und statischer IP bei Bedarf verbunden wird. Am optionalen Port ("APINTERN") --> hängt ein WLAN-AP; Port hat statische IP und hier ist DHCP aktiviert. Die IP-Adressen sind beispielhaft, die FB ist zum Test auf Standard-IP eingestellt. HTTPS-Login am CP ist nicht aktiviert.
Mit einer neuen Card und der Anleitung von "aqui" war das Teil schnell wieder aufgesetzt (Version 2.3.5-Release-p2). Haken ist, dass kein Backup der Einstellungen mehr verfügbar ist (Kein Backup - kein Erbarmen - ich weiss!). Also die Einstellungen des Captive Portals wieder (nach Anleitung) "regeneriert". Mit einer "Alles offen"-Firewall Regel läuft zum Test die Verbindung zum Internet (Notebook via WLAN an APINTERN). Nach Aktivierung des Captive Portals (vorher User, Gruppe und Zuweisung des Portal-Logins auf den User eingerichtet) ist keine Verbindung zum Internet mehr möglich.
Verwunderlich ist, dass die Portalseite (getestet mit Standardseite und eigener login.html) nicht angezeigt wird. Bei direktem Aufruf einer URL kommt ein Timeout. Wenn die pfSense-IP (lokal) mit Port 8000/ 8002 aufgerufen wird erscheint eine weiße Seite. Im Firewall-Log ist kein Eintrag zu finden. Auch die Anlage einer FW-Rule (siehe Screenshot) bringt keine Lösung.
Wo könnte mein Fehler liegen und welche Informationen werden noch benötigt? Im Folgenden noch ein paar Einstellungen im Screenshot.
Ich würde mich über eine paar "Denkanstöße" freuen.
Gruss Frank
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 381756
Url: https://administrator.de/forum/problem-captive-portal-auf-pfsense-mal-wieder-381756.html
Ausgedruckt am: 27.04.2025 um 19:04 Uhr
7 Kommentare
Neuester Kommentar
Du hast mehr oder minder alles richtig gemacht. Etwas unsinnig ist dein Regelwerk am CP Segment.
Dort gibst du Port 8002 frei und dannach dann so oder so alles, da ist die Port 8002 Regel dann eh sinnfrei. Die kannst du dann auch gleich entsorgen, da überflüssig.
Gefährlich ist auch ein Source "any". Das sollte an besser lassen, denn damit erlaubst du jegliche IP als Absender IP. In deinem "APintern" Segment sollten ja auch nur Endgeräte mit diesem Netzwerk als Absender IP durch.
Also besser ist dann Source: APintern_net und Destination any. Die Port 8002 kann entfallen da sinnlos mit der Scheunentor Regel.
Letztlich ist das aber vermutlich nicht dein Problem.
Bedenke das das CP nur durch TCP 80 Traffic getriggert wird und auch nur wenn das Ziel per DNS aufgelöst werden kann. Eine funktionierende DNS Auflösung sollte also gegeben sein. Das kannst du testen wenn du das CP ausschaltest an dem Segment und dann mit dortigen Clients Internet Verbindung hast.
Gib also im Browser mal eine direkte IP und HTTP an um das Portal zu triggern... also http://82.149.225.21 z.B. oder irgendeine RFC 1918 IP wie http://10.1.1.1
Dann sieh auch mal ins Log. Die FW "redet" eigentlich immer mit dir wenn sie Probleme hat
Am WAN Port den Haken bei "Block RFC 1918 IP networks" hast du entfernt ?! Da du eine Kaskade mit einem RFC 1918 IP Netz hast zur FB (192.168.178.0 /24) muss dieser Haken raus !
Nach dem Screenshot oben fehlt das !!!
Noch ein Tip: Grafiken insbesondere RRD Grafiken solltest du mit einem 2D13 Board besser deaktivieren. Die fressen viel Performance.
Ebenso IPv6. Wenn du kein v6 machst deaktiviere das in den Global Settings.
Dort gibst du Port 8002 frei und dannach dann so oder so alles, da ist die Port 8002 Regel dann eh sinnfrei. Die kannst du dann auch gleich entsorgen, da überflüssig.
Gefährlich ist auch ein Source "any". Das sollte an besser lassen, denn damit erlaubst du jegliche IP als Absender IP. In deinem "APintern" Segment sollten ja auch nur Endgeräte mit diesem Netzwerk als Absender IP durch.
Also besser ist dann Source: APintern_net und Destination any. Die Port 8002 kann entfallen da sinnlos mit der Scheunentor Regel.
Letztlich ist das aber vermutlich nicht dein Problem.
Bedenke das das CP nur durch TCP 80 Traffic getriggert wird und auch nur wenn das Ziel per DNS aufgelöst werden kann. Eine funktionierende DNS Auflösung sollte also gegeben sein. Das kannst du testen wenn du das CP ausschaltest an dem Segment und dann mit dortigen Clients Internet Verbindung hast.
Gib also im Browser mal eine direkte IP und HTTP an um das Portal zu triggern... also http://82.149.225.21 z.B. oder irgendeine RFC 1918 IP wie http://10.1.1.1
Dann sieh auch mal ins Log. Die FW "redet" eigentlich immer mit dir wenn sie Probleme hat
Am WAN Port den Haken bei "Block RFC 1918 IP networks" hast du entfernt ?! Da du eine Kaskade mit einem RFC 1918 IP Netz hast zur FB (192.168.178.0 /24) muss dieser Haken raus !
Nach dem Screenshot oben fehlt das !!!
Noch ein Tip: Grafiken insbesondere RRD Grafiken solltest du mit einem 2D13 Board besser deaktivieren. Die fressen viel Performance.
Ebenso IPv6. Wenn du kein v6 machst deaktiviere das in den Global Settings.
Hallo aqui,
vielen Dank für die ausführlichen Tips.
Die "All in" Regel am APINTERN unter 8002 ist vom Testen noch drin. Die 8002er selbst hatte ich aus dem Grund als Test gesetzt, da ich im Forum gelesen hatte, dass ab glaube Version 2.2 dieser Port für CP getriggert wird. Wie verhält es sich dann mit dem Port, wenn https aktiviert ist? Ich habe vor, wenn CP läuft, ein Cert einzubinden. Muss dafür 'ne FW-Regel definiert werden?
Die DNS Auflösung ist ein guter Ansatz - kann ich allerdings erst Ende der Woche testen. Ich werde vom Ergebnis berichten.
Der Haken für die privaten IP-Ranges hatte ich schon entfernt, nur Block Bogon-Netze ist aktiv. Und die Grafiken machen wirklich im scharfen Betrieb keinen Sinn - wer sitzt schon permanent am Monitor und schaut sich remote den Traffic an.
Schöne Woche bis dahin.
vielen Dank für die ausführlichen Tips.
Die "All in" Regel am APINTERN unter 8002 ist vom Testen noch drin. Die 8002er selbst hatte ich aus dem Grund als Test gesetzt, da ich im Forum gelesen hatte, dass ab glaube Version 2.2 dieser Port für CP getriggert wird. Wie verhält es sich dann mit dem Port, wenn https aktiviert ist? Ich habe vor, wenn CP läuft, ein Cert einzubinden. Muss dafür 'ne FW-Regel definiert werden?
Die DNS Auflösung ist ein guter Ansatz - kann ich allerdings erst Ende der Woche testen. Ich werde vom Ergebnis berichten
.Der Haken für die privaten IP-Ranges hatte ich schon entfernt, nur Block Bogon-Netze ist aktiv. Und die Grafiken machen wirklich im scharfen Betrieb keinen Sinn - wer sitzt schon permanent am Monitor und schaut sich remote den Traffic an
.Schöne Woche bis dahin.
... ist vom Testen noch drin.
Besser immer löschen solche Konfig Leichen !8000 oder 8001 wird getriggert je nachdem wieviel CP Segmente du hast. Sieh auf dein URL oben wenn die CP Seite erscheint
Ich werde vom Ergebnis berichten
Wir sind gespannt...
Also,
endlich ist es geschafft. Danke an die tatkräftige Hilfe und die Tipps hier im Forum.
Das Beste vorweg - es funktioniert. Aber, ...
Leider war die genaue Ursache nicht festzustellen. Ich habe nach der Anleitung von aqui (siehe oben) noch einmal die Einstellungen geprüft, hier vor allem die DNS Auflösung getestet. Dabei fiel auf, dass nach dem ersten Auflösen in beide Richtungen (IP in Name und umgekehrt) eine saubere Verbindung via Captive Portal erst dann möglich war, nachdem ich einmal eine Seite per IP aufgerufen hatte.
Der Port für die Login-Seite war übrigens 8002 - default vom System.
Ich vermute folgenden Grund als Ursache für das Ausbleiben der Login-Seite: Beim Testen hatte ich den gleichen Laptop sowohl für den Zugang zur Konfiguration (über LAN-Kabel) UND den Aufruf der Login-Seite über WLAN genutzt. Nachdem ich das Kabel abgesteckt hatte funktionierte alles einwandfrei. Für den Konfigurations-Port wurde in der FW eine Regel definiert, dass kein Zugriff aus dem Captive Portal auf die Konfiguration erfolgen kann.
Hat halt die Faulheit gesiegt . . .
endlich ist es geschafft. Danke an die tatkräftige Hilfe und die Tipps hier im Forum.
Das Beste vorweg - es funktioniert. Aber, ...
Leider war die genaue Ursache nicht festzustellen. Ich habe nach der Anleitung von aqui (siehe oben) noch einmal die Einstellungen geprüft, hier vor allem die DNS Auflösung getestet. Dabei fiel auf, dass nach dem ersten Auflösen in beide Richtungen (IP in Name und umgekehrt) eine saubere Verbindung via Captive Portal erst dann möglich war, nachdem ich einmal eine Seite per IP aufgerufen hatte.
Der Port für die Login-Seite war übrigens 8002 - default vom System.
Ich vermute folgenden Grund als Ursache für das Ausbleiben der Login-Seite: Beim Testen hatte ich den gleichen Laptop sowohl für den Zugang zur Konfiguration (über LAN-Kabel) UND den Aufruf der Login-Seite über WLAN genutzt. Nachdem ich das Kabel abgesteckt hatte funktionierte alles einwandfrei. Für den Konfigurations-Port wurde in der FW eine Regel definiert, dass kein Zugriff aus dem Captive Portal auf die Konfiguration erfolgen kann.
Hat halt die Faulheit gesiegt . . .
erst dann möglich war, nachdem ich einmal eine Seite per IP aufgerufen hatte.
Das zeigt dann aber das du einen Fehler in der DNS Konfig oder den Regeln für DNS hast am CP Interface.Hier solltest du zwingend darauf achten das die DNS Regel (Port 53) zuallererst in der Regelliste steht und zwar für TCP und UDP !
Bevor du das CP dann aktivierst auf dem Interface solltest du es erstmal so wasserdicht testen mit nslookup oder dig das das fehlerlos rennt.
Das ist wichtig, denn die Auflösung MUSS zwingend klappen da das CP ausschliesslich durch einen TCP 80 Request getriggert wird.
Kommt kein TCP 80 Traffic kommt auch kein Captive Portal !!
TCP 80 Traffic kann aber nur kommen wenn der Browser den Hostnamen auflösen kann denn erst danach macht er einen HTTP Request TCP 80 ans Ziel.
Einfacher und simpler Mechanismus !
hatte ich den gleichen Laptop sowohl für den Zugang zur Konfiguration (über LAN-Kabel) UND den Aufruf der Login-Seite über WLAN genutzt.
Das ist natürlich tödlich und weiß man eigentlich auch !Winblows geht dann nach der Bindungsreihenfolge der Adapter, da es mit 2 IP Interfaces bzw. 2 Default gateways NICHT umgehen kann wie man als netzwerker ja weiß.
Das es dann in die Hose geht ist klar, denn dann weisst du nicht ob der Request vom LAN Interface oder WLAN kommt.
In deinem Falle wohl LAN, da es wohl in der Bindungsreihenfolge vor dem WLAN kommt und es dann als Absender Interface genommen wird.
Simpler Anfängerfehler...leider !
Aber gut wenns nun klappt wie es soll.
Hallo nochmal,
@aqui: Du hast selbstverständlich Recht! Wie schon erwähnt hatte ich aus Bequemlichkeit das selbe Gerät benutzt. Der Hinweis mit den FW-Regeln ist echt ganz wichtig. Ich hatte (nach den DNS-Tests) schon meine ganzen "Konfig-Leichen" (siehe Dein Tipp weiter oben) aus den Regeln vor dem "Scharfschalten" des CP entfernt sowie weitere Regeln (53, 443, usw.) hinzugefügt. Um den Thread allerdings nicht zu weit auszuweiten hatte ich diese Details einfach nicht erwähnt.
Nichtsdestotrotz - Vielen Dank noch einmal!
@aqui: Du hast selbstverständlich Recht! Wie schon erwähnt hatte ich aus Bequemlichkeit das selbe Gerät benutzt. Der Hinweis mit den FW-Regeln ist echt ganz wichtig. Ich hatte (nach den DNS-Tests) schon meine ganzen "Konfig-Leichen"
(siehe Dein Tipp weiter oben) aus den Regeln vor dem "Scharfschalten" des CP entfernt sowie weitere Regeln (53, 443, usw.) hinzugefügt. Um den Thread allerdings nicht zu weit auszuweiten hatte ich diese Details einfach nicht erwähnt.Nichtsdestotrotz - Vielen Dank noch einmal!
Alles wird gut...! 
