Konfiguracja i testowanie Captive Portal w Sophos Firewall

Captive Portal loguje użytkowników, którzy są już połączeni z siecią LAN lub WLAN. Następnie Sophos Firewall może przypisać ich ruch do tożsamości użytkownika i zastosować reguły dla określonych użytkowników lub grup.

Istotne jest współdziałanie wszystkich elementów: portal tworzy przypisanie użytkownika, ale sam nie zezwala na dostęp do internetu. Potrzebna jest do tego również odpowiednia reguła firewalla. Niezależnie od niej muszą działać DNS, routing, NAT i segmentacja sieci.

Cały proces obejmuje sześć kroków:

1. Sprawdzić źródło uwierzytelniania i dozwoloną grupę.
2. Zezwolić na Captive Portal dla strefy klientów w Administration > Device access.
3. Jeśli używany jest zewnętrzny serwer DNS, utworzyć wąską regułę DNS bez powiązania z użytkownikiem.
4. Utworzyć regułę użytkownika z opcjami Match known users oraz Use web authentication for unknown users.
5. W Authentication > Web authentication skonfigurować HTTPS, stronę docelową i wylogowanie.
6. Sprawdzić logowanie przez port 8090, użytkownika w Live users oraz Rule ID w Log Viewer.

Co Captive Portal zapewnia, a czego nie

Captive Portal sprawdza się w przypadku urządzeń BYOD, klientów niezarządzanych oraz sieci bez transparentnego rozpoznawania użytkowników. Użytkownik otwiera stronę internetową, zostaje przekierowany do logowania, a następnie firewall wiąże jego tożsamość ze źródłowym adresem IP. Tożsamość może być używana jako kryterium dopasowania reguły.

Inne portale i metody uwierzytelniania służą do innych zadań:

• Wireless Hotspot jest przeznaczony do dostępu gościnnego za pomocą voucherów, hasła dziennego lub warunków korzystania. Kompletny proces opisano w artykule Konfiguracja Hotspot w Sophos Firewall.
• Guest user to tymczasowe konto lokalne dla Captive Portal. Bezpieczne tworzenie i obsługa kont gości opisuje grupę, ważność, wydawanie danych, samodzielną rejestrację i usuwanie kont.
• VPN Portal jest częścią Remote Access. Captive Portal nie tworzy tunelu VPN i nie powinien być używany jako publiczny portal logowania.
• STAS, AD SSO lub SATC mają rozpoznawać użytkowników bez logowania w przeglądarce. W takich środowiskach Captive Portal może być mechanizmem awaryjnym dla urządzeń, na których transparentne rozpoznawanie nie działa.
• Logowanie Microsoft wymaga osobnej procedury Captive Portal z Microsoft Entra ID SSO.

Przegląd portali Sophos pomaga odróżnić User Portal, VPN Portal, WebAdmin i Captive Portal.

⚠️ Captive Portal nie zastępuje segmentacji. Sieć BYOD lub gościnna pozostaje w osobnej strefie albo VLAN i otrzymuje dostęp tylko do rzeczywiście potrzebnych celów i usług. Logowanie poprawia przypisanie użytkownika, ale nie zabezpiecza automatycznie zbyt szeroko udostępnionej sieci.

Wymagania i przykład

Przed rozpoczęciem konfiguracji należy ustalić następujące elementy:

• Działa lokalne lub zewnętrzne źródło uwierzytelniania. W przypadku Active Directory sprawdzono już połączenie z serwerem oraz grupę; konfigurację opisano w artykule Łączenie Active Directory z Sophos Firewall.
• Znane są strefa klientów, sieć źródłowa i dozwolona grupa użytkowników.
• Klient otrzymuje poprawny adres IP, bramę i działające serwery DNS.
• Dla produkcyjnej nazwy portalu istnieje rekord DNS oraz certyfikat akceptowany przez klientów.
• Istniejąca reguła MASQ/SNAT i routing obejmują później dozwolony ruch internetowy.
• Do testu odbiorczego dostępny jest jeden użytkownik dozwolony i jeden niedozwolony.

W przykładzie użyto następujących wartości:

• Strefa klientów: LAN
• Sieć klientów: 10.30.40.0/24
• Obiekt sieciowy: BYOD_10.30.40.0_24
• Adres IP firewalla w strefie klientów: 10.30.40.1
• Grupa użytkowników: BYOD_Internet
• Nazwa reguły: LAN-BYOD-to-WAN-Captive
• Wewnętrzny serwer DNS: 10.20.0.53
• Nazwa portalu: login.example.com

Tych wartości nie należy kopiować bez weryfikacji. Strefa i sieć muszą odpowiadać rzeczywistemu interfejsowi klientów, adres 10.30.40.1 należy zastąpić adresem IP firewalla na tym interfejsie, a grupa musi pochodzić z używanego źródła uwierzytelniania. Z sieci klientów nazwa portalu musi wskazywać dokładnie ten osiągalny adres firewalla.

Konfiguracja Captive Portal krok po kroku

1. Wybór metody uwierzytelniania

W Authentication > Services, w sekcji Firewall authentication methods, określa się źródła, które firewall sprawdza podczas logowania. Może to być lokalna baza użytkowników albo wcześniej skonfigurowany serwer AD, LDAP lub RADIUS. Tworzenie i testowanie zwykłych lokalnych użytkowników opisuje grupę, hasło, Local, Sign-in Restriction i cykl życia tego modelu. Kolejność ma znaczenie: jeśli skonfigurowano kilka serwerów, SFOS sprawdza je od góry do dołu.

W tym przykładzie grupa BYOD_Internet musi być dostępna na firewallu. W przypadku Active Directory należy ją wcześniej zaimportować. Dopiero potem można wybrać ją w regule użytkownika i jednoznacznie sprawdzić przypisanie podczas testu.

Samo poprawne połączenie z serwerem nie wystarcza. Dlatego później trzeba sprawdzić przy użyciu rzeczywistego logowania w portalu, czy hasło, grupa i reguła użytkownika współdziałają prawidłowo.

2. Zezwolenie na Captive Portal dla strefy źródłowej

W Administration > Device access, w wierszu Captive portal, należy zaznaczyć wyłącznie strefy, z których użytkownicy rzeczywiście mają się logować. W przykładzie jest to LAN. Następnie zapisać ustawienie przyciskiem Apply.

Device Access steruje dostępem do lokalnej usługi firewalla. Zwykła reguła LAN-to-WAN nie może zastąpić tego zezwolenia. Jednocześnie nie należy zapobiegawczo udostępniać Captive Portal dla strefy WAN ani dla niepowiązanych stref wewnętrznych. Artykuł Device Access i Local Service ACL opisuje również szczególny przypadek Web Proxy, w którym lokalne portale mogą być osiągalne mimo bardziej restrykcyjnej tabeli stref.

Jeśli klienty używają samego firewalla jako resolvera DNS, w tej samej macierzy trzeba również zezwolić na DNS dla ich strefy. W przypadku osobnego serwera DNS potrzebna jest natomiast opisana niżej reguła tranzytowa.

3. Zapewnienie DNS przed logowaniem

Przeglądarka może otworzyć login.example.com lub pierwotnie żądaną stronę tylko wtedy, gdy DNS działa jeszcze przed uwierzytelnieniem użytkownika. Jeżeli serwer DNS nie znajduje się na firewallu, w Rules and policies > Firewall rules > Add firewall rule > New firewall rule należy utworzyć osobną regułę:

• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: strefa serwera DNS
• Destination networks: obiekt hosta dla 10.20.0.53
• Services: DNS
• Log firewall traffic: włączyć na czas testu odbiorczego

Reguła nie otrzymuje powiązania z użytkownikiem, ponieważ klient nie jest jeszcze uwierzytelniony. Przed logowaniem zezwala się tylko na DNS do przewidzianego resolvera, a nie na dowolny ruch. Jeśli środowisko korzysta z kilku serwerów DNS, należy dodać wyłącznie ich konkretne obiekty hostów.

Regułę DNS należy umieścić tak, aby resolver był osiągalny jeszcze przed logowaniem. W przykładzie znajduje się bezpośrednio przed regułą użytkownika i powyżej każdej bardziej ogólnej reguły, która odrzucałaby lub inaczej przetwarzała ruch DNS z tej sieci. Następnie zapisać ją przyciskiem Save.

Nad tabelą reguł należy wybrać odpowiedni protokół: IPv4 albo IPv6. Jeśli klienty łączą się z resolverem wyłącznie przez IPv4, wystarczy reguła DNS IPv4. Gdy DNS jest używany również przez IPv6, trzeba utworzyć równie wąską regułę IPv6 z właściwymi obiektami sieci i hosta IPv6.

4. Tworzenie reguły użytkownika

Następnie tworzy się właściwą regułę dostępu. W przykładzie otrzymuje ona następujące wartości:

• Rule name: LAN-BYOD-to-WAN-Captive
• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: WAN
• Destination networks: wymagane cele internetowe lub Any
• Services: tylko wymagane usługi
• Match known users: włączone
• Use web authentication for unknown users: włączone
• Users or groups: BYOD_Internet
• Log firewall traffic: włączone

Także tutaj nad tabelą reguł wybiera się IPv4 albo IPv6. W sieci dual-stack należy utworzyć osobną regułę użytkownika z odpowiednimi obiektami sieciowymi dla każdej rzeczywiście dozwolonej rodziny protokołów; reguła IPv4 nie obejmuje IPv6.

Opcja Match known users ustawia tożsamość jako kryterium dopasowania. Use web authentication for unknown users powoduje, że pasujące żądanie WWW od nieuwierzytelnionego użytkownika prowadzi do logowania. Grupa określa, kto po poprawnym uwierzytelnieniu może korzystać z reguły.

W SFOS 22 i 23 opcja Use web authentication for unknown users nie jest jedynym czynnikiem wywołującym logowanie. Gdy jest włączona, pasujące żądanie WWW od nieuwierzytelnionego użytkownika uruchamia uwierzytelnianie. Gdy jest wyłączona, ten przełącznik początkowo zezwala na żądanie bez logowania; przypisana Web Policy może jednak nadal je zablokować i w ten sposób uruchomić uwierzytelnianie WWW. Decydujące jest to, czy Web Policy dla nieznanych użytkowników lub grup ma ustawioną akcję Block. Dalszy przebieg zależy od AD SSO:

• Z AD SSO, zarówno przy wywołaniu przez regułę, jak i przy akcji Block w Web Policy dla nieznanych użytkowników: SFOS najpierw próbuje logowania transparentnego. Jeśli próba się nie powiedzie, następuje przekierowanie do Captive Portal. Po udanym logowaniu strona zostaje ponownie załadowana, a Web Policy użytkownika jest ponownie oceniana.
• Bez AD SSO, z wywołaniem przez regułę: pasujące żądanie WWW od nieuwierzytelnionego użytkownika zostaje bezpośrednio przekierowane do Captive Portal.
• Bez AD SSO, tylko z blokadą przez Web Policy: pojawia się strona blokady. Może być na niej wyświetlany link do Captive Portal; nie należy tu oczekiwać automatycznego przekierowania takiego jak przy wywołaniu przez regułę.

W przypadku nieoczekiwanego logowania lub strony blokady należy więc najpierw łącznie sprawdzić faktycznie dopasowaną regułę w Log Viewer, przełącznik w tej regule, Web Policy dla nieznanych użytkowników lub grup oraz stan AD SSO w Authentication > Web authentication. Przed zmianą należy udokumentować dotychczasowe wartości. Test przeprowadza się na kliencie pilotażowym bez istniejącej sesji i wyłącznie w zakresie przewidzianego dla niego dostępu: nie należy ogólnie usuwać akcji Block, łagodzić reguł użytkowników ani globalnie zmieniać AD SSO tylko po to, aby wymusić przekierowanie. Po zalogowaniu należy sprawdzić Current activities > Live users, użytkownika i Rule ID w Log Viewer oraz jeden dozwolony i jeden nadal blokowany cel. W przypadku nieoczekiwanego zachowania należy przywrócić poprzednie wartości zmienionych ustawień i powtórzyć te same kontrole.

W polu Services wartość Any ma sens tylko wtedy, gdy grupa rzeczywiście ma otrzymać pełny dostęp klienta do internetu po zalogowaniu. W przypadku węższego dostępu należy świadomie wybrać HTTP, HTTPS i inne wymagane protokoły. Ruch inny niż WWW nie może sam wyświetlić strony logowania; użytkownik musi najpierw wywołać uwierzytelnienie w przeglądarce albo przy użyciu bezpośredniego adresu URL portalu.

Reguła musi znajdować się powyżej szerokiej reguły allow opartej na adresach IP. W przeciwnym razie ruch zostanie przetworzony wcześniej i nie dotrze do reguły użytkownika. Po sprawdzeniu kolejności należy zapisać regułę przyciskiem Save. Podstawy przetwarzania reguł wyjaśnia artykuł Prawidłowe planowanie reguł firewalla.

5. Konfiguracja HTTPS, przekierowania i wylogowania

W Authentication > Web authentication nie włącza się dostępności portalu, lecz ustawia jego zachowanie.

Captive Portal przyjmuje maksymalnie po 50 znaków w nazwie użytkownika i haśle. Przed wdrożeniem należy sprawdzić ten limit na rzeczywistym koncie, szczególnie w przypadku zewnętrznych katalogów i automatycznie generowanych nazw użytkowników.

W konfiguracji produkcyjnej ważne są następujące decyzje:

• Show user portal link wyświetla na stronie Captive Portal odnośnik do User Portal. Opcję należy włączyć tylko wtedy, gdy użytkownicy faktycznie potrzebują tego portalu i ma on być osiągalny z ich strefy.
• Use insecure HTTP instead of HTTPS pozostaje wyłączone. HTTP przesyłałby dane logowania bez szyfrowania. Przy użyciu HTTP SFOS 22 nie obsługuje Microsoft Entra ID SSO; w SFOS 23 ograniczenie to dotyczy całego OpenID Connect SSO.
• Show web page after sign-in może przekierować użytkownika do pierwotnie żądanej strony albo do określonej strony wewnętrznej.
• Open web page: In new browser window pozostawia stronę Captive Portal otwartą na potrzeby wylogowania i keepalive. Jeśli zastąpiona zostanie ta sama karta, sposób wylogowania jest dla użytkownika mniej widoczny.
• When captive portal page is closed or redirected wylogowuje użytkownika, gdy firewall przestaje odbierać pakiety keepalive. Może się to zdarzyć również po uśpieniu urządzenia lub zmianie sieci.
• When user is inactive ocenia przedział czasu i ilość przesłanych w nim danych. SFOS wylogowuje użytkownika, którego ruch pozostaje poniżej ustawionego progu. Czas i ilość danych trzeba dobrać tak, aby zwykły ruch w tle nie utrzymywał każdej nieaktualnej sesji bez końca.
• Never wymaga ręcznego wylogowania i może dłużej utrzymywać nieaktualne powiązania użytkownika z adresem IP.

Nie ma jednego właściwego limitu czasu dla wszystkich środowisk. Na urządzeniach współdzielonych i przy zmianach użytkowników ważniejsze są krótsze sesje; na urządzeniach przypisanych do jednej osoby logowanie może być mniej uciążliwe. Każdy wariant należy przetestować podczas uśpienia urządzenia, zmiany WLAN i ręcznego wylogowania. Te lokalne opcje sign-out nie dotyczą Microsoft Entra ID SSO w SFOS 22 ani całego OpenID Connect SSO w SFOS 23.

Przed testem odbiorczym należy zanotować używaną wersję SFOS i metodę logowania. W przypadku tych metod logowania SSO wymienione lokalne opcje sign-out nie są odpowiednim sposobem zapobiegania nieoczekiwanym wylogowaniom; z tego wyjątku nie można wywnioskować ani nieograniczonego czasu sesji, ani konkretnego limitu czasu po stronie IdP. Test SSO należy przeprowadzać wyłącznie przez HTTPS z ważnym, zaufanym certyfikatem. Nie należy włączać HTTP nawet na potrzeby diagnostyki. Logowanie, widoczne przypisanie użytkownika i wylogowanie należy sprawdzić z kontem pilotażowym w rzeczywiście używanym procesie SSO, zamiast zakładać działanie lokalnych przełączników sign-out.

Dodatkowo Authentication > Services > Global settings > Maximum session timeout ogranicza całkowity czas sesji zalogowanych użytkowników. SFOS sprawdza autoryzację co trzy minuty; sesję mogą też zakończyć Access Policies, Surfing Quota i limit transferu danych. Ta globalna wartość dotyczy nie tylko Captive Portal, dlatego przed zmianą trzeba sprawdzić inne metody uwierzytelniania.

Po dokonaniu wyboru zapisać ustawienia przyciskiem Apply.

Device Console zawiera też globalne wartości minimalnych wersji TLS dla Captive Portal, X-Frame-Options oraz ciąg szyfrów współdzielony z Web Proxy. Bezpieczne sprawdzanie ustawień HTTP Proxy wyjaśnia, dlaczego nie jest to ogólna lista optymalizacji oraz jak przetestować i wycofać zmianę za pomocą prób portalu i proxy.

W Captive portal appearance można dostosować logo, teksty i kolory. Jeśli zamiast domyślnego układu używany jest Custom HTML, trzeba zachować działający znacznik <div id="__loginbox"></div> oraz wymagany przez Sophos blok request-url z odpowiednim skryptem przekierowania. Własny kod HTML, CSS lub JavaScript należy więc najpierw sprawdzić przez Preview, a następnie z kontem pilotażowym. Poprawny wygląd portalu nie oznacza sukcesu, jeśli szablon zakłóca logowanie, przekierowanie lub wylogowanie; Reset to default pozwala cofnąć personalizację.

<div id="__loginbox"></div>
<div id="request-url" style="display:none;">{url}</div>
<script>
var redirect_url = document.getElementById("request-url").innerHTML;
</script>

Część ze skryptem należy umieścić bezpośrednio przed </body>.

6. Sprawdzenie nazwy portalu i certyfikatu

Bezpośredni adres diagnostyczny ma postać:

https://<Firewall-IP>:8090

W przykładzie można najpierw otworzyć https://10.30.40.1:8090. W środowisku produkcyjnym bardziej zrozumiały jest adres https://login.example.com:8090, o ile nazwa wskazuje na firewall i znajduje się w certyfikacie.

Adres IP służy wyłącznie do sprawdzenia osiągalności. Jeśli wybrany certyfikat obejmuje tylko login.example.com, przeglądarka przy otwarciu 10.30.40.1 zgodnie z oczekiwaniem wyświetli ostrzeżenie o niezgodności nazwy. Po pominięciu tego ostrzeżenia nie należy wprowadzać danych logowania. Dlatego współdziałanie DNS i certyfikatu należy zawsze sprawdzać za pomocą nazwy FQDN.

Należy przejść do Administration > Admin and user settings. Przed zmianą trzeba zanotować bieżącą wartość Redirect users i wybrany Certificate. Następnie w sekcji Admin console and end-user interaction, pod Redirect users, wybiera się Firewall’s configured hostname lub A different hostname; w przykładzie należy wpisać login.example.com. W sekcji Certificate wybiera się certyfikat obejmujący tę nazwę. Przed wdrożeniem konfigurację przekierowania sprawdza się przyciskiem Check settings. Wybór certyfikatu dotyczy nie tylko Captive Portal, lecz także innych lokalnych portali firewalla. Dlatego po zmianie trzeba również sprawdzić WebAdmin, User Portal i VPN Portal.

Jeśli którykolwiek test zakończy się niepowodzeniem, należy ponownie wybrać zanotowaną wartość przekierowania i poprzedni certyfikat, a następnie zapisać przyciskiem Apply. Potem trzeba ponownie sprawdzić przekierowanie i portale.

Certyfikat zaufany publicznie eliminuje ostrzeżenia na urządzeniach niezarządzanych. W przypadku wewnętrznego urzędu certyfikacji lub CA podpisanego przez firewall certyfikat CA musi być zainstalowany jako zaufany na wszystkich klientach. Nazwę certyfikatu, pełny łańcuch i bezpieczne przypisanie opisano w artykule Zarządzanie certyfikatami na Sophos Firewall.

Pełny test logowania i reguły użytkownika

Test odbiorczy rozpoczyna się na kliencie bez aktywnej sesji. W razie potrzeby starą sesję testową można zakończyć w Current activities > Live users.

1. Sprawdzić, czy klient otrzymał adres z sieci 10.30.40.0/24, właściwą bramę i poprawny serwer DNS.
2. Bezpośrednio otworzyć https://10.30.40.1:8090, aby sprawdzić dostępność portalu niezależnie od automatycznego przekierowania w przeglądarce. Jeśli certyfikat zawiera tylko login.example.com, ostrzeżenie o niezgodności nazwy jest oczekiwane. Następnie otworzyć adres FQDN, aby zweryfikować DNS i certyfikat.
3. Bez aktywnej sesji otworzyć zwykłą stronę HTTP i sprawdzić przekierowanie do Captive Portal. Strona HTTPS z zapamiętanym mechanizmem HSTS nie jest wiarygodnym testem.
4. Zalogować się jako dozwolony użytkownik. Jeśli włączono lokalne Sophos MFA, token OTP musi zostać wcześniej zarejestrowany w User Portal. Konfigurację opisano w artykule Włączanie MFA w Sophos Firewall.
5. W Current activities > Live users sprawdzić nazwę użytkownika, adres IP klienta i typ uwierzytelniania.
6. Przetestować dozwoloną stronę oraz cel albo usługę, które celowo nie zostały udostępnione.
7. W Log Viewer odfiltrować adres IP klienta. Wpis musi wskazywać oczekiwanego użytkownika oraz Rule ID reguły LAN-BYOD-to-WAN-Captive.
8. Przy użyciu użytkownika spoza grupy BYOD_Internet sprawdzić, czy logowanie nie zapewnia dostępu przez tę regułę.
9. Wywołać wylogowanie, uśpienie urządzenia lub zmianę sieci i sprawdzić, kiedy użytkownik znika z Live users.

W sieci dual-stack test należy wykonać osobno dla IPv4 i IPv6. SFOS utrzymuje oba przypisania użytkownika oddzielnie, a obie wersje protokołu wymagają odpowiednich reguł firewalla; dlatego udany test IPv4 nie potwierdza jeszcze działającego dostępu IPv6.

Ukierunkowana diagnostyka typowych błędów

Portal się nie pojawia

Najpierw należy otworzyć bezpośredni adres URL na porcie 8090. Jeśli nie jest osiągalny, sprawdzić strefę źródłową, opcję Captive portal w Device Access, adres IP klienta, przypisanie stref, DNS oraz FQDN portalu.

Jeśli adres bezpośredni działa, ale automatyczne logowanie się nie pojawia, ruch często jest wcześniej przetwarzany przez bardziej ogólną regułę albo brakuje opcji Use web authentication for unknown users. Ponadto logowanie w przeglądarce może wywołać tylko pasujące żądanie WWW. Programy, które nie korzystają z WWW, nie wyświetlą strony Captive Portal.

Logowanie jest odrzucane

W Authentication > Services należy sprawdzić źródło uwierzytelniania i kolejność. Następnie zweryfikować połączenie z serwerem, hasło, grupę użytkownika, quota, a przy lokalnym MFA także ukończoną rejestrację OTP. Cykliczne dozwolone lub blokowane godziny dostępu sprawdza się oddzielnie za pomocą Access Time dla użytkowników i grup. Procedura Surfing Quota i Network Traffic Quota pokazuje, czy zamiast tego wyczerpano wykorzystany czas internetu lub limit danych.

Jeżeli błąd nie jest jednoznacznie związany z portalem, artykuł Systematyczne rozwiązywanie błędów uwierzytelniania na Sophos Firewall rozdziela osiągalność, wybór usługi, Live Users, Main Group i późniejszą ścieżkę ruchu.

Dla klasycznych prób logowania istotny jest plik access_server.log. Plik oauth_sso_captive.log jest potrzebny wyłącznie w procesie SSO z Microsoft Entra ID. Artykuł Logi usług Sophos Firewall wyjaśnia, jak czytać pliki bez przedwczesnego restartowania usług.

Logowanie udane, ale brak dostępu

Udane logowanie potwierdza wyłącznie uwierzytelnienie. Następnie strefa klientów, sieć źródłowa, grupa, cele, usługi, pozycja reguły, NAT i routing muszą odpowiadać regule użytkownika. Log Viewer pokazuje, która Rule ID rzeczywiście przetwarza ruch. W systematycznej analizie pomaga artykuł Dlaczego reguła Sophos Firewall nie jest dopasowywana.

Użytkownik zostaje niespodziewanie wylogowany

Należy sprawdzić wybraną opcję sign-out oraz jej progi czasu i danych, otwarte okno portalu, uśpienie urządzenia, zmianę sieci i bezczynność. Trzeba też sprawdzić Maximum session timeout w Authentication > Services > Global settings, a także Access Time, Surfing Quota i Network Traffic Quota. Przy opcji When captive portal page is closed or redirected przypisanie kończy się, gdy przestają docierać pakiety keepalive; nie musi to być widoczne dokładnie w chwili zamknięcia okna.

Logowanie pojawia się dopiero po około dwóch minutach

Jeśli w tej samej sieci używany jest STAS, jego faza uczenia może opóźnić przekierowanie. Najpierw należy wtedy sprawdzić stan STAS i nieuwierzytelnionych klientów. Ogólna procedura Captive Portal nie zmienia w tym celu żadnej globalnej wartości CLI; zależności opisano w artykule o STAS.

Kilku użytkowników korzysta z tego samego źródłowego adresu IP

Captive Portal zasadniczo przypisuje tożsamość użytkownika do adresu IP klienta. Dlatego adresy IP dodane w Multi-user hosts na potrzeby Per-Connection AD SSO przez Direct Web Proxy nie mogą korzystać z Captive Portal. Per-Connection AD SSO dla hostów wielu użytkowników opisuje właściwą procedurę i osobną regułę bez Match known users dla pozostałego ruchu.

Częste pytania