21
Captive Portal durch UAP-AC läst sich nicht aufrufen
Guten Tag,
Was genau braucht (Netzwerk basierend) ein "Captive Portal"?
Ich habe bei mir im zwei ähnlich aufgebauten Netzwerken ein ähnliches Problem.
Meine Topologie sieht folgendermaßen aus: DigitalisierungsBox Premium (Modem)> Pfsense > L2 Switch > UAP-AC-Pro-Gen2
Das WLAN funktioniert grundsätzlich recht gut, jedoch gelingt es mir nicht, das Captive Portal zum Laufen zu bringen. Weder das von Unifi noch von pfSense. Dabei habe ich festgestellt, dass das Portal von pfSense meinen Anforderungen besser entspricht. Mit nur wenigen Schritten habe ich es schnell eingerichtet. Nun stoße ich allerdings auf das Problem. Sobald ich versuche, über ein Gerät, das über den Access Point verbunden ist, auf das Portal zuzugreifen, kommt es zu einem Timeout. Über LAN funktioniert das Captive Portal einwandfrei, wenn ich hier eine Seite aufrufen möchte, so werde ich recht schnell an das Port 8002 der Gateway weiter geleitet. Und dieses Phänomen tritt an beiden Standorten auf.
Hat jemand eine Idee, woran das liegen könnte?
pfSense = 2.7
Controller = Netzwerk 7.3.83
UAP-AC-Pro = Version: 6.5.62.14788
Viele Grüße
Ich
Was genau braucht (Netzwerk basierend) ein "Captive Portal"?
Ich habe bei mir im zwei ähnlich aufgebauten Netzwerken ein ähnliches Problem.
Meine Topologie sieht folgendermaßen aus: DigitalisierungsBox Premium (Modem)> Pfsense > L2 Switch > UAP-AC-Pro-Gen2
Das WLAN funktioniert grundsätzlich recht gut, jedoch gelingt es mir nicht, das Captive Portal zum Laufen zu bringen. Weder das von Unifi noch von pfSense. Dabei habe ich festgestellt, dass das Portal von pfSense meinen Anforderungen besser entspricht. Mit nur wenigen Schritten habe ich es schnell eingerichtet. Nun stoße ich allerdings auf das Problem. Sobald ich versuche, über ein Gerät, das über den Access Point verbunden ist, auf das Portal zuzugreifen, kommt es zu einem Timeout. Über LAN funktioniert das Captive Portal einwandfrei, wenn ich hier eine Seite aufrufen möchte, so werde ich recht schnell an das Port 8002 der Gateway weiter geleitet. Und dieses Phänomen tritt an beiden Standorten auf.
Hat jemand eine Idee, woran das liegen könnte?
pfSense = 2.7
Controller = Netzwerk 7.3.83
UAP-AC-Pro = Version: 6.5.62.14788
Viele Grüße
Ich
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 12893915067
Url: https://administrator.de/forum/captive-portal-durch-uap-ac-laest-sich-nicht-aufrufen-12893915067.html
Ausgedruckt am: 25.12.2024 um 14:12 Uhr
21 Kommentare
Neuester Kommentar
Moin,
Heißt das, dass die Default-Seite gar nicht geladen wird? Dann stimmt etwas nicht mit Deinen Firewall-Regeln.
LAN und WLAN sind das selbe Netz oder getrennt in VLANs?
Gruß
Looser
Sobald ich versuche, über ein Gerät, das über den Access Point verbunden ist, auf das Portal zuzugreifen, kommt es zu einem Timeout.
Heißt das, dass die Default-Seite gar nicht geladen wird? Dann stimmt etwas nicht mit Deinen Firewall-Regeln.
Über LAN funktioniert das Captive Portal einwandfrei, wenn ich hier eine Seite aufrufen möchte, so werde ich recht schnell an das Port 8002 der Gateway weiter geleitet.
LAN und WLAN sind das selbe Netz oder getrennt in VLANs?
Gruß
Looser
Hallo,
naja im Zweifel google Server? Normal aber kein Timeout, sondern "Sie sind nicht verbunden".
Hatte vor Jahren es mit OPNsense aufgebaut. "Sie sind nicht verbunden" kann man ignorieren und kommt trotzdem weiter. Grund war/ ist wohl, dass z.B. Android google Server sucht. Findet es nichts, kommt besagte Meldung.
Normal sollte aber die Standard-Anleitung immer das Captive Portal vorspülen.
Oder hast du beim Testen dri das WLAN abgegraben? Ein System muss dabei führen. pfsense. Kenne deine APs nicht. Die von Zyxel haben ja teils eigens CP mit integiert.
Welches LAN geht denn? Wenn du noch manged Switch hast, würde ich mal das Kabel vom AP direkt in den Laptop stecken. Um zu testen, ob ganz trivial diese Strecke ohne Probleme geht. Nicht dass durch falsches VLAN o.ä. du ein generelles Problem hast.
Also: ist das LAN Kabel genau jenes, welches auch den AP versorgt?
mfg Crusher
naja im Zweifel google Server? Normal aber kein Timeout, sondern "Sie sind nicht verbunden".
Hatte vor Jahren es mit OPNsense aufgebaut. "Sie sind nicht verbunden" kann man ignorieren und kommt trotzdem weiter. Grund war/ ist wohl, dass z.B. Android google Server sucht. Findet es nichts, kommt besagte Meldung.
Normal sollte aber die Standard-Anleitung immer das Captive Portal vorspülen.
Oder hast du beim Testen dri das WLAN abgegraben? Ein System muss dabei führen. pfsense. Kenne deine APs nicht. Die von Zyxel haben ja teils eigens CP mit integiert.
Welches LAN geht denn? Wenn du noch manged Switch hast, würde ich mal das Kabel vom AP direkt in den Laptop stecken. Um zu testen, ob ganz trivial diese Strecke ohne Probleme geht. Nicht dass durch falsches VLAN o.ä. du ein generelles Problem hast.
Also: ist das LAN Kabel genau jenes, welches auch den AP versorgt?
mfg Crusher
PS: Bist du überhaupt sauber verbunden?
Nicht das durch oben geschilderte Probelmatik Handy auf andere SSID springt.
Und nur test01 ist sauber eingerichtet. Manche APs haben ja mehrere. Und wenn dann das Device glaubt intelligenter als du zu sein, hast du ein Problem.
Auch hier wäre ggf. es nicht verkehrt, den AP zu sichern und zu resetten. Um eine saubere Ausgangssituation zu schaffen.
Nicht das durch oben geschilderte Probelmatik Handy auf andere SSID springt.
test01
test02
test03Und nur test01 ist sauber eingerichtet. Manche APs haben ja mehrere. Und wenn dann das Device glaubt intelligenter als du zu sein, hast du ein Problem.
Auch hier wäre ggf. es nicht verkehrt, den AP zu sichern und zu resetten. Um eine saubere Ausgangssituation zu schaffen.
Verzeihung, wie immer habe ich die Problematik nicht vollständig oder teilweise falsch beschrieben.
Wenn ich eine URL in die Adresszeile eingebe, beginnt das Laden, jedoch wird keine Verbindung hergestellt.
Ursprünglich habe ich einfach ein anderes VLAN zum Portal hinzugefügt, und dort hat es funktioniert. Daher ging ich davon aus, dass das Problem unbedingt an dem Access Point liegen muss.
Nun habe ich einen Laptop an den Switch mit LAN in dem betroffenen VLAN angeschlossen ... und siehe da, genau dasselbe Problem wie mit dem Handy.
Die Firewall-Regel sieht wie folgt aus:
NAT:
Wenn ich eine URL in die Adresszeile eingebe, beginnt das Laden, jedoch wird keine Verbindung hergestellt.
Ursprünglich habe ich einfach ein anderes VLAN zum Portal hinzugefügt, und dort hat es funktioniert. Daher ging ich davon aus, dass das Problem unbedingt an dem Access Point liegen muss.
Nun habe ich einen Laptop an den Switch mit LAN in dem betroffenen VLAN angeschlossen ... und siehe da, genau dasselbe Problem wie mit dem Handy.
Die Firewall-Regel sieht wie folgt aus:
NAT:
Zitat von @Crusher79:
Sobald ich das Portal der pfSense deaktiviere, kann ich ganz normal auf alle Webseiten zugreifen.
Also OPNsense haben wir Gastnetzwerk. DHCP etc.
https://www.google.com/search?client=firefox-b-d&q=pfsense+captive+p ...
Oder nochmal Video anschauen ob du was übersehen hast?
In den Regeln ist any zu any ganz unten. Normal ist das Captive Portal ja ein Dienst, der über die URL aufgerufen wird. Irgendwie fehlt da doch was. Es sei denn, pfsense arbeitet da ganz anders.
https://docs.opnsense.org/manual/how-tos/guestnet.html
Bei der Konkurrenz ist da einiges los. Netz einrichten, DHCP.
Ich rate dir nochmal auf Anfang zu gehen und die Anleitungen abzuarbeiten.
https://www.google.com/search?client=firefox-b-d&q=pfsense+captive+p ...
Oder nochmal Video anschauen ob du was übersehen hast?
In den Regeln ist any zu any ganz unten. Normal ist das Captive Portal ja ein Dienst, der über die URL aufgerufen wird. Irgendwie fehlt da doch was. Es sei denn, pfsense arbeitet da ganz anders.
https://docs.opnsense.org/manual/how-tos/guestnet.html
Bei der Konkurrenz ist da einiges los. Netz einrichten, DHCP.
Ich rate dir nochmal auf Anfang zu gehen und die Anleitungen abzuarbeiten.
1
Was genau braucht (Netzwerk basierend) ein "Captive Portal"?
Es braucht nur die Mac Adresse des Clients und TCP 80 oder 443 Traffic der das Portal triggert!Bei pfSense / OPNsense muss zusätzlich im Regelwerk noch der Port der Portalseite VOR allen Regeln erlaubt werden!
Guckst du hier:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
Bei pfSense beginnen die Regeln oben und werden nach unten abgearbeitet. Das dort oben ist auch der oberste Abschnitt.
DHCP ist ebenfalls aktiv.
Ich habe gerade eine neue Schnittstelle unter pfSense mit einem neuen VLAN eingerichtet und dieser Schnittstelle das Portal zugewiesen.
Nachdem ich meinen Laptop angeschlossen habe, hat es etwa 5 Sekunden gedauert, bis es mich aufgefordert hat, mich im Netzwerk anzumelden. Nachdem ich auf die Schaltfläche 'Anmelden' geklickt habe, vergingen weitere 10 Sekunden, und das Portal hat sich tatsächlich geöffnet. Ich habe zugestimmt, und das Internet funktionierte. Nun habe ich versucht, das Gerät vom Portal zu trennen und das neue VLAN im Unifi einzurichten, um es mit dem Gast-WLAN zu verbinden. Doch wieder das gleiche Problem.
Ich beschäftige mich seit letztem Freitag mit diesem Problem und habe das gesamte Wochenende damit verbracht.
Ich habe die Anleitung von pfSense mindestens fünfmal durchgelesen und einmal sogar mit einem Übersetzer. Zudem habe ich mir vier verschiedene Videos angesehen. Ich möchte nicht übermäßig klagen, aber ja, ich bin ein wenig frustriert. :/
DHCP ist ebenfalls aktiv.
Ich habe gerade eine neue Schnittstelle unter pfSense mit einem neuen VLAN eingerichtet und dieser Schnittstelle das Portal zugewiesen.
Nachdem ich meinen Laptop angeschlossen habe, hat es etwa 5 Sekunden gedauert, bis es mich aufgefordert hat, mich im Netzwerk anzumelden. Nachdem ich auf die Schaltfläche 'Anmelden' geklickt habe, vergingen weitere 10 Sekunden, und das Portal hat sich tatsächlich geöffnet. Ich habe zugestimmt, und das Internet funktionierte. Nun habe ich versucht, das Gerät vom Portal zu trennen und das neue VLAN im Unifi einzurichten, um es mit dem Gast-WLAN zu verbinden. Doch wieder das gleiche Problem.
Ich beschäftige mich seit letztem Freitag mit diesem Problem und habe das gesamte Wochenende damit verbracht.
Ich habe die Anleitung von pfSense mindestens fünfmal durchgelesen und einmal sogar mit einem Übersetzer. Zudem habe ich mir vier verschiedene Videos angesehen. Ich möchte nicht übermäßig klagen, aber ja, ich bin ein wenig frustriert. :/
Hast Du am Switch die VLANs korrekt eingerichtet?
Hast Du am Unifi AP das Netzwerk inkl. VLAN-ID korrekt eingerichtet?
Gruß
Looser
Hast Du am Unifi AP das Netzwerk inkl. VLAN-ID korrekt eingerichtet?
Gruß
Looser
Das ist es ja.
Wenn es falsch eingerichtet gewesen wäre, dann würde es doch bei einem deaktivierten CP keine Verbindung zur den Seiten geben.
Richtig?
Wenn es falsch eingerichtet gewesen wäre, dann würde es doch bei einem deaktivierten CP keine Verbindung zur den Seiten geben.
Richtig?
WLAN über DHCP? Feste IP da rein gerutscht? Ggf. Mit falscher SNM etc?
Mehrere DHCP? Hat der AP auch einen?
?
Einmal LAN und einmal WLAN.
Unterschiede?
Mehrere DHCP? Hat der AP auch einen?
Ipconfig /allEinmal LAN und einmal WLAN.
Unterschiede?
Moin,
eine Frage zum Verständnis.
Rufst Du das Portal auf mit der Angabe des Ports auf? x.x.x.x:8002
Würde mal unter den Sites im IIS Manager schauen, welcher Port für den Zugriff dort eingestellt ist.
Kann aber auch total falsch liegen.
eine Frage zum Verständnis.
Rufst Du das Portal auf mit der Angabe des Ports auf? x.x.x.x:8002
Würde mal unter den Sites im IIS Manager schauen, welcher Port für den Zugriff dort eingestellt ist.
Kann aber auch total falsch liegen.
IP und Maske wird richtig vergeben. Also wie gesagt, sobald das Portal deakteviert ist funktioniert WLAN und auch LAN.
Mehrere DHCP? Hat der AP auch einen?
Ich gehe davon aus, dass DHCP wenn überhaupt, nur bei der USG vorhanden ist. bei einem Unifi Switch kann ich es mir nicht vorstellen. USG hatte ich hier nie dran gehabt und der Switch von denen ist … halt nichts meins.. daher wieder zurück geschickt.
Ipconfig /allEinmal LAN und einmal WLAN.
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether b0:0c:d1:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet 10.2.88.2/24 brd 10.2.88.255 scope global dynamic noprefixroute enp1s0
valid_lft 6804sec preferred_lft 6804sec
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 0c:96:e6:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet 10.2.88.15/24 brd 10.2.88.255 scope global dynamic noprefixroute wlp2s0
valid_lft 7189sec preferred_lft 7189sec
inet6 fe80::cf46:849a:da26:4991/64 scope link noprefixroute
valid_lft forever preferred_lft forevervon Handy WLAN
egal ob ich auf die Weiterleitung warte oder auch direkt auf den Port versuche zuzugreifen.
Was mir jedoch gerade aufgefallen ist, dass wenn ich auf dem Handy 10.2.88.1:8002 eingebe, es mich darauf hin an 10.2.88.1:8000 umleitet.
Würde mal unter den Sites im IIS Manager schauen, welcher Port für den Zugriff dort eingestellt ist.
Was meinst du bitte mit IIS? Du mein nicht den "Internet Information Services" von Windows?
Ich denke, dass ich die Lösung gefunden habe.
Problem Nr1: Mein Handy (P10) ist zu alt
Problem Nr2: Das Gastportal von Unifi, war noch an, und somit hat es dazwischen gefunkt. Daher auch die Umleitung auf Port 8000.
Problem Nr3: WiFi Type einfach nur von "Guest Hotspot" auf "Standard" umschalten reicht scheinbar nicht. Man muss unbedingt das GastPortal ausschalten und erst dann auf Standard stellen.
Problem Nr4: FireFox musste ich neu starten bevor es die Umleitung des Ports der Anmeldung von der pfSense greift.
Ich werde dies jetzt noch einmal bei dem zweiten Standort verifizieren und dann noch einmal endgültig bestätigen.
Ich danke euch allen für eure Unterstützung schon einmal und wünsche euch einen schönen Feierabend.
Problem Nr1: Mein Handy (P10) ist zu alt
Problem Nr2: Das Gastportal von Unifi, war noch an, und somit hat es dazwischen gefunkt. Daher auch die Umleitung auf Port 8000.
Problem Nr3: WiFi Type einfach nur von "Guest Hotspot" auf "Standard" umschalten reicht scheinbar nicht. Man muss unbedingt das GastPortal ausschalten und erst dann auf Standard stellen.
Problem Nr4: FireFox musste ich neu starten bevor es die Umleitung des Ports der Anmeldung von der pfSense greift.
Ich werde dies jetzt noch einmal bei dem zweiten Standort verifizieren und dann noch einmal endgültig bestätigen.
Ich danke euch allen für eure Unterstützung schon einmal und wünsche euch einen schönen Feierabend.
Problem Nr1: Mein Handy (P10) ist zu alt
Zumindestens nicht für das pfSense oder OPNsense CP. Das rennt auch mit einem 10 Jahre alten iPad und anderen älteren mobilen Endgeräten problemlos. Warum auch nicht es wird ja lediglich von stinknormalen Port TCP 80 oder 443 Traffic getriggert. Das konnten auch schon alle Betriebssystem vor 20 Jahren und älter. Punkt 3 gibt es zumindestens auf dem pfSense CP nirgendwo als Einstellung. Was soll damit gemeint sein?
Räusper. Das meinte ich auch mit 2. DHCP Server. Irgendein Dienst...
Das mit den resetten oben meine ich ernst. Zumal man ja die AP Konfig zuvor noch sichern kann.... Manchmal ist es beser bei Null zu beginnen ....
Das mit den resetten oben meine ich ernst. Zumal man ja die AP Konfig zuvor noch sichern kann.... Manchmal ist es beser bei Null zu beginnen ....
Guten Tag,
Ja, genau das habe ich mir auch gedacht. Und dennoch kann ich mich zum Beispiel am Standort zwei überhaupt nicht anmelden, während andere Geräte ohne Probleme weitergeleitet werden. Am Standort eins, bei dem ich dachte, alles eingerichtet zu haben, gab es am nächsten Morgen erneut einen kompletten WAN-Ausfall. Vor einem halben Jahr musste ich eine selbstgebaute pfSense austauschen, weil ich herausgefunden hatte, dass die fest verlötete CPU mit dem 1-Gbit-NIC nicht richtig zurechtkam. Dann kam das 2.7 Update, und der Fehler verschwand auch am Standort eins. Nur habe ich hier 10-Gbit-NICs eingebaut.
Verzeihung, aqua. Ja, es handelt sich um die Einstellung im Unifi-Controller.
Aber ist es wirklich dann ein DHCP was da arbeitet?
Das mit den resetten oben meine ich ernst. Zumal man ja die AP Konfig zuvor noch sichern kann.... Manchmal ist es beser bei Null zu beginnen ....
Ich habe auch die WLAN-Konfiguration am Controller für das betroffene Netzwerk und das Netzwerk (VLAN) gelöscht und neu eingerichtet. Das hat leider auch nichts gebracht.
Und jetzt noch einmal die Frage: Was genau sendet im Netzwerk die Aufforderung, sich anzumelden? Gestern habe ich an beiden Standorten gleichzeitig unter einem Linux-Desktop eine Aufforderung erhalten, mich am Netzwerk anzumelden. Das Netzwerk selbst ist dabei nicht ausgefallen. Und jetzt der wichtigste Punkt: Das Captive Portal am Standort eins ist seit dem Ausfall deaktiviert.
Viele Grüße
Ich
Zitat von @aqui:
Problem Nr1: Mein Handy (P10) ist zu alt
Zumindestens nicht für das pfSense oder OPNsense CP. Das rennt auch mit einem 10 Jahre alten iPad und anderen älteren mobilen Endgeräten problemlos. Warum auch nicht es wird ja lediglich von stinknormalen Port TCP 80 oder 443 Traffic getriggert. Das konnten auch schon alle Betriebssystem vor 20 Jahren und älter. Ja, genau das habe ich mir auch gedacht. Und dennoch kann ich mich zum Beispiel am Standort zwei überhaupt nicht anmelden, während andere Geräte ohne Probleme weitergeleitet werden. Am Standort eins, bei dem ich dachte, alles eingerichtet zu haben, gab es am nächsten Morgen erneut einen kompletten WAN-Ausfall. Vor einem halben Jahr musste ich eine selbstgebaute pfSense austauschen, weil ich herausgefunden hatte, dass die fest verlötete CPU mit dem 1-Gbit-NIC nicht richtig zurechtkam. Dann kam das 2.7 Update, und der Fehler verschwand auch am Standort eins. Nur habe ich hier 10-Gbit-NICs eingebaut.
Punkt 3 gibt es zumindestens auf dem pfSense CP nirgendwo als Einstellung. Was soll damit gemeint sein?
Verzeihung, aqua. Ja, es handelt sich um die Einstellung im Unifi-Controller.
Aber ist es wirklich dann ein DHCP was da arbeitet?
Das mit den resetten oben meine ich ernst. Zumal man ja die AP Konfig zuvor noch sichern kann.... Manchmal ist es beser bei Null zu beginnen ....
Ich habe auch die WLAN-Konfiguration am Controller für das betroffene Netzwerk und das Netzwerk (VLAN) gelöscht und neu eingerichtet. Das hat leider auch nichts gebracht.
Und jetzt noch einmal die Frage: Was genau sendet im Netzwerk die Aufforderung, sich anzumelden? Gestern habe ich an beiden Standorten gleichzeitig unter einem Linux-Desktop eine Aufforderung erhalten, mich am Netzwerk anzumelden. Das Netzwerk selbst ist dabei nicht ausgefallen. Und jetzt der wichtigste Punkt: Das Captive Portal am Standort eins ist seit dem Ausfall deaktiviert.
Viele Grüße
Ich
DHCP ist nur immer eine Vermutung. Die Dinger sind entweder nur stumpf auf eine Sache ausgelegt, oder können halt mehr. Bei Netzwerk vertut man sich mitunter. Statische IP, wieder zurück zu DHCP... Dann mal OK Button nicht richtig gedrückt und alles bleibt beim Alten.
Falsche Subnetzmaske sorgt dafür, dass Server im gleichen Netz erreichbar sind. Versucht man es aus anderen VLAN z.b. geht es nicht....
Captive Portal ist wie DHCP u.a. ein Dienst. Damit der angesprochen wird muss man entweder den direkt aufrufen oder Weiterleitungen im Hintergrund eingerichtet haben.
Es gibt sehr robuste Hardware, die bei Kunden jahrelang läuft. Deine H/W Probleme oben sind unschön gewesen. Ist aber nicht das Maß der Dinge. pfsense wie OPNsense sind an sich beide stabil.
Weinn ein Dienst nicht läuft, sollte auch keine Reaktion erfolgen. Kein Captive Portal. Etwas diffus bei dir .....
Falsche Subnetzmaske sorgt dafür, dass Server im gleichen Netz erreichbar sind. Versucht man es aus anderen VLAN z.b. geht es nicht....
Captive Portal ist wie DHCP u.a. ein Dienst. Damit der angesprochen wird muss man entweder den direkt aufrufen oder Weiterleitungen im Hintergrund eingerichtet haben.
Es gibt sehr robuste Hardware, die bei Kunden jahrelang läuft. Deine H/W Probleme oben sind unschön gewesen. Ist aber nicht das Maß der Dinge. pfsense wie OPNsense sind an sich beide stabil.
Weinn ein Dienst nicht läuft, sollte auch keine Reaktion erfolgen. Kein Captive Portal. Etwas diffus bei dir .....
1
Das stimmt. Das gefällt mir auch nicht.
Hast du eine Idee, was genau im Netzwerk gesendet werden muss, um einem neuem Gerät das Signal zu geben sich irgend wo anmelden zu müssen?
Hast du eine Idee, was genau im Netzwerk gesendet werden muss, um einem neuem Gerät das Signal zu geben sich irgend wo anmelden zu müssen?
Das wird generell durch jeglichen TCP 80 bzw. TCP 443 Traffic getriggert. Bei der den Sensen 443 nur wenn HTTPS aktiviert wurde im Setup.
Dabei ist zu beachten das der o.a. relevante Traffic nur kommt wenn zuvor ein DNS Request erfolgreich war um einen Hostnamen aufzulösen. Ohne erfolgreichen DNS kein TCP 80 / 443 Traffic und auch kein Captive Portal. DNS im Regelwerk ist also ein Schlüssel für eine erfolgreiche Portalseite!
Alternativ um DNS Problematiken zu umgehen gibt man im Browser URL die direkte IP ein. Z.B. http://193.99.144.85
Dabei ist zu beachten das der o.a. relevante Traffic nur kommt wenn zuvor ein DNS Request erfolgreich war um einen Hostnamen aufzulösen. Ohne erfolgreichen DNS kein TCP 80 / 443 Traffic und auch kein Captive Portal. DNS im Regelwerk ist also ein Schlüssel für eine erfolgreiche Portalseite!
Alternativ um DNS Problematiken zu umgehen gibt man im Browser URL die direkte IP ein. Z.B. http://193.99.144.85
Hmm komsich.
Normal kann man es über die GUI steuern und das System sollte das tun, was man verlangt. Initial ist es aber oft nicht verkehrt den Wizard durchlaufen zu lassen. Hast du die pfsense "nach Standard" einmal durchkonfiguriert und dann Schritt für Schritt das Ganze verfeinert?
Patchstand aktuell? Ggf. die Geschichte mal rebooten? Auf geeigneter Hardware ist die Unterbrechung sehr kurz. Auf Servern kommt erst POST, SAS RAID Controller etc. Das bringt dann schonmal Probleme mit sich.
Es gibt ja auch sowas wie Unbound DNS. Auf meiner OPNsense gab es mal Probleme, dass der Dienst nicht mehr lief. Ist ja dann auch klar...
Geeignete Hardare, Wizard einmal durchlaufen lassen und pfsense initial einrichten. Ggf. Logs kontrollieren ob es doch Ausreißer gibt. Alle Netzwerke Geräte soweit kastrieren, dass die pfsense führt. DHCP, Catpive Portal etc. ausschalten.
Auch an kleine Repeater denken! Diese Steckdosen Teile werden immer intelligenter. Bringen eigenen DHCP Server mit und laufen von Haus aus teils nicht als Repeater sondern als AP. Mitunter überbrückt man damit kurze Strecken und denkt nicht mehr daran.
Wenn du absolut nicht sicher bist schau ob du während der arbeitsfreien Zeit Segmente mal Off schalten kannst um das Problem einzugrenzen.
Wenn du noch nicht viel konfiguriert hast ist auch ein Reset eine Option. Die jetzige Konfig kannst du ja einfach swohl von pfsense als auch den APs sichern....
Kann nur eine Kleinigkeit seien. Nur ohne direkt davor zu sitzen ist es schwer.
@aqui brachte schon IP Direktaufruf ein. Manche kommen auf die Idee und stellen als Failover eine einfacher IP virtuell bereit, damit man nicht viel tippen muss: Sowas wie 1.1.1.1 sollte man sich aber verkneifen, da wieder andere Anbieter dahinter stecken.
Reboot und/ oder von vorne Anfangen erleichtet ggf. die Fehlersuche. Bzw. lässt den im kleinen Kreis gar nicht erst auf kommen.
Normal kann man es über die GUI steuern und das System sollte das tun, was man verlangt. Initial ist es aber oft nicht verkehrt den Wizard durchlaufen zu lassen. Hast du die pfsense "nach Standard" einmal durchkonfiguriert und dann Schritt für Schritt das Ganze verfeinert?
Patchstand aktuell? Ggf. die Geschichte mal rebooten? Auf geeigneter Hardware ist die Unterbrechung sehr kurz. Auf Servern kommt erst POST, SAS RAID Controller etc. Das bringt dann schonmal Probleme mit sich.
Es gibt ja auch sowas wie Unbound DNS. Auf meiner OPNsense gab es mal Probleme, dass der Dienst nicht mehr lief. Ist ja dann auch klar...
Geeignete Hardare, Wizard einmal durchlaufen lassen und pfsense initial einrichten. Ggf. Logs kontrollieren ob es doch Ausreißer gibt. Alle Netzwerke Geräte soweit kastrieren, dass die pfsense führt. DHCP, Catpive Portal etc. ausschalten.
Auch an kleine Repeater denken! Diese Steckdosen Teile werden immer intelligenter. Bringen eigenen DHCP Server mit und laufen von Haus aus teils nicht als Repeater sondern als AP. Mitunter überbrückt man damit kurze Strecken und denkt nicht mehr daran.
Wenn du absolut nicht sicher bist schau ob du während der arbeitsfreien Zeit Segmente mal Off schalten kannst um das Problem einzugrenzen.
Wenn du noch nicht viel konfiguriert hast ist auch ein Reset eine Option. Die jetzige Konfig kannst du ja einfach swohl von pfsense als auch den APs sichern....
Kann nur eine Kleinigkeit seien. Nur ohne direkt davor zu sitzen ist es schwer.
@aqui brachte schon IP Direktaufruf ein. Manche kommen auf die Idee und stellen als Failover eine einfacher IP virtuell bereit, damit man nicht viel tippen muss: Sowas wie 1.1.1.1 sollte man sich aber verkneifen, da wieder andere Anbieter dahinter stecken.
Reboot und/ oder von vorne Anfangen erleichtet ggf. die Fehlersuche. Bzw. lässt den im kleinen Kreis gar nicht erst auf kommen.
