Seit Update auf iOS 17.3 Probleme sich mit WLAN zu verbinden - Captive Wi-Fi

Ich hatte das gleiche Problem und bin dann dahintergekommen, woran es liegt. Ich hatte dem Standardprofil an der FRITZ!Box das Internet entzogen („Internetzugang: nie“)! Jedes Gerät, also auch mein IPhone, eben auch nach dem kompletten Zurücksetzen der Netzwerkeinstellungen, hat sich zuerst mit dem „Standard-Profil“ der FRITZ!Box verbunden und hatte kein Internet, und ist deswegen davon ausgegangen, dass es sich um ein public Netzwerk handelt (Zu erkennen auch in den Verbindungsdetails am IPhone, wenn der „Auto-Login“ Schieber sichtbar ist. Lösung war, Internet für das Standardprofil an der FRITZ!Box einzuschalten, das IPhone zu verbinden, dann auf dieses auf ein anderes, unbeschränktes Profile zu konfigurieren und die Einstellung für das Standardnetzwerk wieder auf „nie“ zu seztzen. Jetzt ist es am IPhone wieder ein private Netzwerk, ohne die ständige captive.apple.com Abfrage
 
Hallo zusammen,
kann es sein, dass mit iOS 18.4 und macOS 15.4 Sequoia wieder ein Problem mit der WLAN Verbindung und "Captive-WLAN" aufgetreten ist? Nach den entsprechenden Updates bekomme ich plötzlich sowohl auf dem Mac als auch iPhones/iPads eine "Captive WLAN-Seite" bei der Anmeldung im Heimnetz angezeigt, die es vorher nicht gab. Mein Heimnetz ist definitiv kein Captive WLAN - in der FritzBox ist kein Captive WLAN aktiviert. In den iOS/iPadOS Geräten taucht auch der Schieber "Autom. anmelden" im WLAN Netz auf. Schalte ich diesen aus, so verschwindet die Anmeldeseite, aber es wäre mir schon lieb, wenn die Endgeräte mein Heimnetz von vorne herein gleich als solches erkennen würden. Hat noch jemand dieses Problem?
Danke und Gruß, Phoenix1000
 
Ich umgehe das Problem mittlerweile mit Geräteprofilen. Einfach mit Apple Configurator ein wifi-Profil für alle relevanten Netzwerke für iPhones und iPads erstellen und dort hinterlegen.
IMG_2173.jpeg
Wichtig ist in dem Profil das Abschalten der MAC Randomisation und das Einschalten des Captive Bypass.
Oder so lösen, wie von @Bet32978 vorgeschlagen. Das sollte auch gehen, das Problem ergibt sich der Erfahrung nach nur bei Fritzboxen mit umkonfiguriertem (= gesperrten) Standardprofil.
 
Da müßten in den iOS-Geräten dann vor dem Neuverbinden erst noch die Netzwerkverbindungen komplett zurückgesetzt werden. Dann sollte es eigentlich funktionieren.
 
Ich umgehe das Problem mittlerweile mit Geräteprofilen. Einfach mit Apple Configurator ein wifi-Profil für alle relevanten Netzwerke für iPhones und iPads erstellen und dort hinterlegen.
Anhang anzeigen 10466

Kann es sein, dass selbst die Profile nichts (mehr) nützen?

Habe hier iOS 26.4.2, FritzBox 6591 Cable@FritzOS 8.21. iOS-Profil wie angegeben und bekomme dennoch ab und an die captive.apple.com-Seite zu sehen.

Allerdings macht hier nicht die Fritz das DNS, sondern ein PiHole 6.4.2.

PiHole explodiert förmlich, wenn man an einem iPhone das WLAN anschaltet. Aber nur zwei Anfragen werden geblockt:
_dns.resolver.arpa ; das hat irgendwas mit "DNS over HTTPS" zu tuen und könnte eine DNS-Auflösung an PiHole vorbei erlauben, daher wurde dies wohl in 2025 implementiert, dass dies geblockt wird. Quelle

Die zweite geblockte Anfrage ist app-measurement.com (ist wohl ein Tracker, der in verschiedenen Apps drin steckt).

Interessant ist, dass trotz CaptiveBaypass = true das iPhone regelmässig Anfragen nach captive.apple.com (HTTPS, AAAA, A) versendete, die vom PiHole auch alle beantwortet wurden. Die Antworten kamen dabei nicht aus dem Cache, sondern aus einem Formward, waren also "ganz frisch". Allerdings dauerten sie mit >20ms etwas länger. Und die Antwort war keine IP, sondern ein CNAME. Mal ins Terminal:
Code:
nslookup captive.apple.com
Server:        192.168.178.235
Address:    192.168.178.235#53

Non-authoritative answer:
captive.apple.com    canonical name = captive.g.aaplimg.com.
Name:    captive.g.aaplimg.com
Address: 17.253.57.199
Name:    captive.g.aaplimg.com
Address: 17.253.57.205

Und ja, es folgte dann noch eine Anfrage nach captive.g.aaplimg.com, allerdings nur nach dem HTTPS-Record. Einen solchen gibt es aber für diese Domain nicht quelle, nur AAAA oder A. Also hat der PiHole mit NODATA geantwortet (aus einem 2min-Cache). iOS hat aber nach der HTTPS-Abfrage gleich aufgegeben und nicht, wie bei der vorherigen captive.apple.com noch die AAAA und A hinterhergeschoben.

Könnte hierin die Crux begraben sein?
 

Letzte Anleitungen

Statistik des Forums

Themen
7.990
Beiträge
78.637
Mitglieder
8.689
Neuestes Mitglied
Kalle0808
Zurück
Oben