Konfigurera och testa Sophos Firewall Captive Portal

Captive Portal loggar in användare som redan är anslutna till ett LAN eller WLAN. Därefter kan Sophos Firewall koppla deras trafik till en användaridentitet och tillämpa regler för specifika användare eller grupper.

Samspelet är viktigt: portalen skapar användarkopplingen, men ger inte i sig internetåtkomst. Det krävs också en matchande brandväggsregel. DNS, routing, NAT och nätverkssegmentering måste fungera oberoende av detta.

Hela processen kan sammanfattas i sex steg:

1. Kontrollera autentiseringskälla och tillåten grupp.
2. Tillåt Captive Portal för klientzonen under Administration > Device access.
3. Skapa en begränsad DNS-regel utan användarkoppling om en extern DNS-server används.
4. Skapa en användarregel med Match known users och Use web authentication for unknown users.
5. Ange HTTPS, målsida och utloggning under Authentication > Web authentication.
6. Kontrollera inloggningen via port 8090, användaren under Live users och Rule ID i Log Viewer.

Vad Captive Portal gör – och inte gör

Captive Portal passar för BYOD-enheter, ohanterade klienter och nätverk där transparent användaridentifiering inte är tillgänglig. Användaren öppnar en webbplats, omdirigeras till inloggningen och kopplas därefter till sin käll-IP-adress på brandväggen. Brandväggen kan använda identiteten som matchningskriterium.

Andra portaler och autentiseringsmetoder löser andra uppgifter:

• En Wireless Hotspot är avsedd för gäståtkomst med voucher, dagslösenord eller användarvillkor. Hela processen finns i Konfigurera Sophos Firewall Hotspot.
• En Guest user är ett tillfälligt lokalt konto för Captive Portal. Skapa och hantera gästanvändare säkert förklarar grupp, giltighet, utlämning, självregistrering och rensning.
• VPN Portal hör till Remote Access. Captive Portal skapar ingen VPN-tunnel och ska inte användas som en offentlig inloggningsportal.
• STAS, AD SSO eller SATC identifierar användare utan webbläsarinloggning när det är möjligt. I sådana miljöer kan Captive Portal vara en reservlösning för enheter där den transparenta identifieringen inte fungerar.
• För en Microsoft-inloggning gäller den separata processen Captive Portal med Microsoft Entra ID SSO.

Översikten över Sophos-portaler hjälper när skillnaden mellan User Portal, VPN Portal, WebAdmin och Captive Portal ännu inte är tydlig.

⚠️ Captive Portal ersätter inte segmentering. Ett BYOD- eller gästnät ska ligga i en egen zon eller VLAN och bara få åtkomst till de mål och tjänster som verkligen behövs. Inloggningen förbättrar användarkopplingen, men gör inte automatiskt ett alltför öppet nätverk säkert.

Förutsättningar och exempel

Följande punkter ska vara fastställda innan konfigurationen påbörjas:

• En lokal eller extern autentiseringskälla fungerar. För Active Directory har serveranslutning och grupp redan kontrollerats. Konfigurationen förklaras i Anslut Active Directory till Sophos Firewall.
• Klientzon, källnätverk och tillåten användargrupp är kända.
• Klienten får en korrekt IP-adress, gateway och fungerande DNS-servrar.
• Det finns en DNS-post och ett certifikat som klienterna litar på för portalens produktionsnamn.
• En befintlig MASQ-/SNAT-regel och routingen omfattar den internettrafik som senare ska tillåtas.
• En tillåten och en otillåten testanvändare är tillgängliga för verifieringen.

Exemplet använder:

• Klientzon: LAN
• Klientnätverk: 10.30.40.0/24
• Nätverksobjekt: BYOD_10.30.40.0_24
• Brandväggens IP i klientzonen: 10.30.40.1
• Användargrupp: BYOD_Internet
• Regelnamn: LAN-BYOD-to-WAN-Captive
• Intern DNS-server: 10.20.0.53
• Portalnamn: login.example.com

Dessa värden får inte kopieras utan kontroll. Zonen och nätverket måste stämma överens med det faktiska klientgränssnittet, 10.30.40.1 ersätts med brandväggens IP på detta gränssnitt och gruppen måste komma från den autentiseringskälla som används. Från klientnätverket måste portalnamnet slå upp exakt till denna nåbara brandväggsadress.

Konfigurera Captive Portal steg för steg

1. Välj autentiseringsmetod

Under Authentication > Services och Firewall authentication methods anges vilka källor brandväggen ska kontrollera vid en inloggning. Det kan vara den lokala användardatabasen eller en tidigare konfigurerad AD-, LDAP- eller RADIUS-server. Skapa och testa normala lokala användare beskriver grupp, lösenord, Local, Sign-in Restriction och livscykel för denna modell. Ordningen är viktig: om det finns flera servrar kontrollerar SFOS dem uppifrån och ned.

I exemplet måste gruppen BYOD_Internet finnas på brandväggen. För Active Directory importeras den först. Därefter kan den väljas i användarregeln och kopplingen kan verifieras entydigt vid testet.

En lyckad serveranslutning räcker inte. Därför kontrolleras senare med en riktig portalinloggning att lösenord, grupp och användarregel fungerar tillsammans.

2. Tillåt Captive Portal för källzonen

Aktivera under Administration > Device access, på raden Captive portal, bara de zoner där användare verkligen ska kunna logga in. I exemplet är det LAN. Spara sedan med Apply.

Device Access styr åtkomsten till en lokal tjänst på brandväggen. En vanlig LAN-to-WAN-regel kan inte ersätta denna behörighet. Captive Portal ska inte heller öppnas förebyggande för WAN eller interna zoner som inte berörs. Device Access och Local Service ACL förklarar även Web Proxy-specialfallet där lokala portaler kan vara nåbara trots en mer begränsad zontabell.

Om klienterna använder själva brandväggen som DNS-resolver måste även DNS tillåtas för deras zon i samma matris. Om en separat DNS-server används krävs i stället följande transitregel.

3. Tillåt DNS före inloggningen

En webbläsare kan bara öppna login.example.com eller den ursprungligen begärda webbplatsen om DNS fungerar redan före användarinloggningen. Om DNS-servern inte finns på brandväggen skapas en separat regel under Rules and policies > Firewall rules > Add firewall rule > New firewall rule:

• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: DNS-serverns zon
• Destination networks: värdobjekt för 10.20.0.53
• Services: DNS
• Log firewall traffic: aktivera för verifieringen

Regeln får ingen användarkoppling eftersom klienten ännu inte är autentiserad. Endast DNS till den avsedda resolvern tillåts, inte godtycklig trafik före inloggningen. Om miljön använder flera DNS-servrar läggs deras specifika värdobjekt till.

Placera DNS-regeln så att resolvern kan nås redan före inloggningen. I exemplet står den direkt före användarregeln och ovanför mer allmänna regler som skulle blockera eller behandla DNS från detta nätverk på annat sätt. Spara sedan med Save.

Välj tillämpligt protokoll, IPv4 eller IPv6, ovanför regeltabellen. Om klienterna endast når resolvern via IPv4 räcker IPv4-DNS-regeln. Om DNS även används via IPv6 skapar du en lika begränsad IPv6-regel med rätt IPv6-nätverks- och värdobjekt.

4. Skapa användarregeln

Nu skapas den faktiska åtkomstregeln. I exemplet får den följande värden:

• 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: nödvändiga internetdestinationer eller Any
• Services: endast nödvändiga tjänster
• Match known users: aktiverat
• Use web authentication for unknown users: aktiverat
• Users or groups: BYOD_Internet
• Log firewall traffic: aktiverat

Välj även här IPv4 eller IPv6 ovanför regeltabellen. I ett dual-stack-nät skapar du en separat användarregel med lämpliga nätverksobjekt för varje protokollfamilj som faktiskt ska tillåtas; en IPv4-regel omfattar inte IPv6.

Match known users gör identiteten till ett matchningskriterium. Use web authentication for unknown users gör att en matchande webbförfrågan från en ännu inte autentiserad användare leder till inloggningen. Gruppen avgör vem som får använda regeln efter en lyckad inloggning.

I SFOS 22 och 23 är Use web authentication for unknown users inte det enda som utlöser en inloggning. Om alternativet är aktiverat utlöser en matchande webbförfrågan från en ännu inte autentiserad användare autentiseringen. Om det är avaktiverat tillåter detta alternativ först förfrågan utan inloggning. En tilldelad Web Policy kan dock fortfarande blockera den och därmed utlösa webbautentiseringen. Avgörande är om en Web Policy för okända användare eller grupper är inställd på Block. Det fortsatta förloppet beror på AD SSO:

• Med AD SSO, både när regeln utlöser autentiseringen och vid Block genom en Web Policy för okända användare: SFOS försöker först med transparent inloggning. Om den misslyckas omdirigeras användaren till Captive Portal. Efter en lyckad inloggning laddas sidan om och användarens Web Policy utvärderas på nytt.
• Utan AD SSO, när regeln utlöser autentiseringen: Den matchande webbförfrågan från en ännu inte autentiserad användare omdirigeras direkt till Captive Portal.
• Utan AD SSO, när endast en Web Policy blockerar: En blockeringssida visas. Den kan innehålla en länk till Captive Portal, men en automatisk omdirigering som när regeln utlöser autentiseringen är inte att förvänta här.

För länken på blockeringssidan finns ett separat alternativ i XML-API:et: DisplayCaptivePortalLink inom WebAuthentication / WebAuthenticationSettings; tillåtna inmatningsvärden är Enable och Disable. Det ska inte förväxlas med DisplayUserPortalLink respektive Show user portal link: det andra alternativet visar en länk till User Portal på Captive Portal-sidan. Den äldre API-beskrivningen beskriver det första alternativet med Enable som en omdirigering och med Disable som visning av Access Denied. Detta kan inte användas som ett universellt alternativ för omdirigering: beskrivningen av webbautentisering för SFOS 22 och 23 skiljer uttryckligen mellan de ovan nämnda fallen med regel, Web Policy och AD SSO och beskriver en blockeringssida med en valfri portallänk när endast en Web Policy blockerar och AD SSO inte används. Beskrivningarna stämmer inte överens i sina generella formuleringar; API-värdet ensamt garanterar därför ingen automatisk omdirigering. Vid följande pilottest kontrolleras även att den avsedda portallänken är synlig i det fall med blockeringssida som faktiskt är tillämpligt.

Vid en oväntad inloggning eller blockeringssida kontrolleras därför först vilken regel som faktiskt matchar i Log Viewer, alternativet i den regeln, Web Policy för okända användare eller grupper och status för AD SSO under Authentication > Web authentication tillsammans. Dokumentera de befintliga värdena före en ändring. Testa med en pilotklient utan befintlig session och endast för dess avsedda åtkomst: häv inte Block generellt, gör inte användarregler mindre restriktiva och ändra inte AD SSO globalt bara för att tvinga fram en omdirigering. Efter inloggningen kontrolleras Current activities > Live users, användare och Rule ID i Log Viewer samt en tillåten destination och en destination som fortfarande är blockerad. Vid oväntat beteende återställs de ändrade värdena och samma kontroller upprepas.

Under Services är Any bara lämpligt om gruppen verkligen ska få full internetåtkomst som klient efter inloggningen. För mer begränsad åtkomst väljs HTTP, HTTPS och andra nödvändiga protokoll medvetet. Trafik som inte är webbaserad kan inte själv visa en inloggningssida. Användaren måste först utlösa inloggningen i en webbläsare eller via portalens direkta URL.

Regeln måste ligga ovanför en bred IP-baserad allow-regel. Annars behandlas trafiken tidigare och når aldrig användarregeln. Kontrollera positionen och spara med Save. Den grundläggande regelutvärderingen förklaras i Planera brandväggsregler korrekt.

5. Ange HTTPS, omdirigering och utloggning

Under Authentication > Web authentication aktiveras inte portalens nåbarhet, utan dess beteende konfigureras.

Om AD SSO redan är konfigurerat behöver även valet av mekanism ingå i bedömningen. Under Authentication > Web authentication är Kerberos & NTLM dokumenterat som standard för SFOS 22 och 23: båda mekanismerna erbjuds i autentiseringsheaderna och webbläsaren väljer en av dem. NTLM only är avsett för äldre klienter som inte kan hantera Kerberos-header. I XML-API:et motsvaras detta av UseKerberosForADSSO inom WebAuthentication / WebAuthenticationSettings: Enable använder Kerberos tillsammans med NTLM, Disable endast NTLM. Kerberos ska inte avaktiveras globalt bara för att tvinga fram en Captive Portal-inloggning. En motiverad ändring av mekanism kräver en egen, avgränsad testplan: kontrollera först den befintliga AD-anslutningen, förutsättningarna för Kerberos och de berörda klienterna, spara det tidigare värdet och kontrollera transparent inloggning samt portalen som reservlösning med en pilotklient. Vid en regression återställs det sparade värdet och testet upprepas; i övrigt lämnas den befintliga AD SSO-konfigurationen oförändrad.

Captive Portal accepterar högst 50 tecken vardera för användarnamn och lösenord. Testa gränsen med ett riktigt konto före utrullningen, särskilt med externa kataloger och automatiskt genererade användarnamn.

Följande val är viktiga i en produktionskonfiguration:

• Show user portal link visar en länk till User Portal på Captive Portal-sidan. Aktivera den endast om användarna verkligen behöver portalen och den ska vara nåbar från deras zon.
• Use insecure HTTP instead of HTTPS ska förbli avaktiverat. HTTP skulle överföra inloggningsuppgifterna okrypterat. SFOS 22 stöder inte Microsoft Entra ID SSO med detta alternativ; i SFOS 23 gäller begränsningen för OpenID Connect SSO som helhet.
• Show web page after sign-in kan omdirigera användaren till den ursprungligen begärda sidan eller till en angiven intern sida.
• Open web page: In new browser window håller Captive Portal-sidan öppen för logout och keepalives. Om samma flik ersätts är utloggningsförloppet mindre synligt för användaren.
• When captive portal page is closed or redirected loggar ut användaren när brandväggen inte längre tar emot keepalives. Det kan också inträffa efter viloläge eller ett nätverksbyte.
• When user is inactive utvärderar en tidsperiod och mängden data som överförs under den. SFOS loggar ut en användare vars trafik ligger under det konfigurerade tröskelvärdet. Välj period och datamängd så att normal bakgrundstrafik inte håller alla inaktuella sessioner aktiva utan tidsgräns.
• Never kräver manuell utloggning och kan behålla inaktuella kopplingar mellan användare och IP-adresser längre.

Det finns ingen timeout som är rätt för alla. På delade enheter och när användarna byts ofta är kortare sessioner viktigare. På personligt tilldelade enheter kan inloggningen få vara mindre störande. Varje val testas med viloläge, WLAN-byte och manuell utloggning. Dessa lokala sign-out-alternativ gäller i SFOS 22 inte för Microsoft Entra ID SSO och i SFOS 23 inte för OpenID Connect SSO som helhet.

Före godkännandet dokumenteras vilken SFOS-version och inloggningsmetod som används. De nämnda lokala sign-out-alternativen är inte ett lämpligt sätt att motverka oväntade utloggningar vid dessa SSO-inloggningar. Undantaget innebär varken att sessionen är obegränsad eller att en viss IdP-timeout gäller. SSO-testet ska fortsatt använda HTTPS med ett giltigt, betrott certifikat. HTTP aktiveras inte heller för felsökning. Inloggning, synlig användarkoppling och utloggning kontrolleras med ett pilotkonto i det SSO-förlopp som faktiskt används, i stället för att förutsätta att de lokala sign-out-alternativen har någon effekt.

Dessutom begränsar Authentication > Services > Global settings > Maximum session timeout den totala tiden för inloggade användare. SFOS kontrollerar behörigheten var tredje minut; även Access Policies, Surfing Quota och gränsen för dataöverföring kan avsluta en session. Det globala värdet påverkar fler metoder än Captive Portal, så kontrollera andra autentiseringsmetoder innan det ändras.

Spara valet med Apply.

Device Console innehåller även globala värden för lägsta TLS-versioner i Captive Portal, X-Frame-Options och en chiffersträng som delas med Web Proxy. Kontrollera HTTP-proxyinställningar säkert förklarar varför dessa värden inte är en generell trimningslista och hur en ändring testas och återställs med portal- och proxyprov.

Under Captive portal appearance kan logotyp, texter och färger anpassas. Den som använder Custom HTML i stället för standardlayouten måste behålla platshållaren <div id="__loginbox"></div> och Sophos föreskrivna request-url-block med tillhörande omdirigeringsskript i fungerande skick. Egen HTML, CSS eller JavaScript testas därför först med Preview och därefter med ett pilotkonto. En visuellt korrekt portal är inte en framgång om mallen bryter inloggning, omdirigering eller utloggning; med Reset to default kan anpassningen återställas.

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

Skriptdelen ska placeras omedelbart före </body>.

Återställningsbasen och den aktiva layouten är inte samma sak. I XML-API:et ändrar operationen Update default settings of captive portal med elementet DefaultCaptivePortal de standardvärden som enligt XML-kommentaren används för Reset to default och för fält som inte kan anpassas via det vanliga gränssnittet. Detta ska skiljas från den aktiva utformningen via WebAuthentication / CaptivePortalAppearance. I exemplet med standardvärden finns, utöver etiketter och HTML, även DoNotClosePage, WillBeSignedOut, SigningIn samt texter för inmatningsvalidering. Detta är portaltexter, inte alternativ som styr det faktiska sessions- eller utloggningsbeteendet. Om denna återställningsbas har anpassats via API:et får Reset to default inte betraktas som en garanterad återställning till en oförändrad fabrikslayout. Det går inte heller att dra någon slutsats om tenantspecifikt beteende utifrån detta.

Det publicerade exemplet med standardvärden är inte en fullständig ersättningsmall för automatisering. Det innehåller HTML input som platshållare; dessutom förekommer EnterValidUsername i XML-exemplet men inte i parametertabellen, medan SsoSignedOut och CredentialLoginButtonLabel endast finns i tabellen. Detta ger varken en tillförlitlig, fullständig fältlista eller stöd för att utelämnade fält förblir oförändrade vid en ändring. Före ett sådant ingrepp säkerhetskopieras de befintliga standardvärdena och den aktiva anpassningen separat, och en versionsanpassad återställningsväg fastställs för båda. Om dessa värden saknas eller återställningsvägen är oklar genomförs inte API-ändringen; återställningsknappen ersätter i synnerhet inte en säkerhetskopia av standardvärdena.

För operationen för standardvärden dokumenterar API:et operationsstatus 200 med Operation Successful. och 500 med Operation Fail.. För Web Authentication Settings anges också 200 och 500; den statiska källan ger dock ingen fullständigt formulerad svarstext för dessa. Detta är operationsstatusar, inte HTTP-statuskoder eller ett fullständigt XML-svar att återskapa. Även ett lyckat resultat anger endast utfallet av konfigurationsoperationen, inte att inloggningen fungerar, att den förväntade omdirigeringen sker eller att utloggningen får avsedd effekt. Efter en godkänd ändring krävs fortfarande Preview och test med ett pilotkonto över HTTPS med ett betrott certifikat: kontrollera inloggning, omdirigering, användarkoppling och utloggning. Vid ett fel återställs de säkerhetskopierade värdena för det område som faktiskt ändrats och samma kontroller upprepas.

6. Kontrollera portalnamn och certifikat

Den direkta diagnostikadressen är:

https://<Firewall-IP>:8090

I exemplet kan https://10.30.40.1:8090 öppnas först. För produktion är https://login.example.com:8090 tydligare, förutsatt att namnet slår upp till brandväggen och ingår i certifikatet.

IP-adressen är endast avsedd för nåbarhetstestet. Om det valda certifikatet enbart omfattar login.example.com visar webbläsaren som förväntat en varning om namnkonflikt när 10.30.40.1 öppnas. Ange inga inloggningsuppgifter efter att ha kringgått varningen. Kontrollera därför alltid via FQDN att DNS och certifikatet fungerar tillsammans.

Gå till Administration > Admin and user settings. Dokumentera det aktuella värdet för Redirect users och valt Certificate före ändringen. I Admin console and end-user interaction väljer du sedan under Redirect users Firewall’s configured hostname eller A different hostname. För exemplet anges login.example.com. Under Certificate väljs certifikatet som omfattar namnet. Testa omdirigeringen med Check settings före utrullningen. Certifikatvalet påverkar inte bara Captive Portal utan även andra lokala brandväggsportaler. Testa därför även WebAdmin, User Portal och VPN Portal efter ändringen.

Om något av testerna misslyckas väljer du det dokumenterade omdirigeringsvärdet och det tidigare certifikatet och sparar med Apply. Testa sedan omdirigeringen och portalerna igen.

Ett publikt betrott certifikat undviker varningar på ohanterade enheter. Med en intern CA eller en CA som signerats av brandväggen måste CA:n vara installerad som betrodd på alla klienter. Certifikatnamn, fullständig kedja och säker tilldelning förklaras i Hantera certifikat på Sophos Firewall.

För ett portalcertifikat som signerats lokalt av brandväggens CA Default öppnar man Certificates > Certificate authorities och väljer Download för Default. Packa upp det offentliga CA-certifikatet som en .pem-fil ur det nedladdade .tar.gz-arkivet och distribuera det kontrollerat till de avsedda klienterna. I Windows importeras det till Trusted Root Certification Authorities; på andra plattformar används motsvarande certifikatlager för betrodda CA:er. Lita endast på den verifierade CA som faktiskt utfärdat certifikatet och distribuera aldrig en privat CA-nyckel. För ett externt utfärdat portalcertifikat måste i stället hela certifikatkedjan, inklusive mellanliggande certifikat, finnas på brandväggen. Kontrollera därefter FQDN-adressen på en berörd klient och bekräfta att ingen certifikatvarning visas.

Testa inloggning och användarregel fullständigt

Verifieringen börjar med en klient utan en befintlig session. Under Current activities > Live users kan en gammal testsession kopplas från vid behov.

1. Kontrollera att klienten har fått en adress från 10.30.40.0/24, avsedd gateway och rätt DNS-server.
2. Öppna https://10.30.40.1:8090 direkt för att testa portalens nåbarhet oberoende av en automatisk omdirigering i webbläsaren. En namnvarning är förväntad om certifikatet endast innehåller login.example.com. Öppna därefter FQDN-adressen för att validera DNS och certifikatet.
3. Öppna en vanlig HTTP-sida utan en befintlig session och kontrollera omdirigeringen till Captive Portal. En HTTPS-sida med lagrat HSTS-beteende är inte ett tillförlitligt test för detta.
4. Logga in med en tillåten användare. Om lokal Sophos MFA är aktiverad måste OTP-token först registreras i User Portal. Konfigurationen finns i Aktivera MFA för Sophos Firewall.
5. Kontrollera användarnamn, klient-IP och autentiseringstyp under Current activities > Live users.
6. Testa en tillåten webbplats och avsiktligt även en destination eller tjänst som inte är tillåten.
7. Filtrera på klientens IP-adress i Log Viewer. Posten måste visa den förväntade användaren och Rule ID för LAN-BYOD-to-WAN-Captive.
8. Kontrollera med en användare utanför BYOD_Internet att inloggningen inte ger åtkomst via denna regel.
9. Utlös utloggning, viloläge eller nätverksbyte och kontrollera när användaren försvinner från Live users.

I ett dual-stack-nät testas IPv4 och IPv6 separat. SFOS hanterar de två användarkopplingarna var för sig och båda protokollvarianterna kräver lämpliga brandväggsregler. Ett lyckat IPv4-test visar därför inte att IPv6-åtkomsten fungerar. Användare måste logga in separat för åtkomst till IPv4- och IPv6-webbplatser; en andra inloggningsuppmaning innebär därför inte automatiskt ett fel.

Felsök vanliga fel systematiskt

Portalen visas inte

Öppna först den direkta URL:en på port 8090. Om den inte går att nå kontrolleras källzonen och Captive portal under Device Access, klientens IP-adress, zonmappning, DNS och portalens FQDN.

Om den direkta URL:en är nåbar men den automatiska inloggningen inte visas, behandlas trafiken ofta först av en mer allmän regel eller så saknas Use web authentication for unknown users. Dessutom kan endast en matchande webbförfrågan utlösa webbläsarinloggningen. Program som inte är webbaserade visar ingen Captive Portal-sida.

Inloggningen avvisas

Kontrollera autentiseringskälla och ordning under Authentication > Services. Kontrollera därefter serveranslutning, lösenord, användargrupp, kvot och, vid lokal MFA, att OTP-registreringen är slutförd. Återkommande tillåtna eller blockerade åtkomsttider kontrolleras separat med Access Time för användare och grupper. Arbetsflödet för Surfing Quota och Network Traffic Quota visar om förbrukad internettid eller datamängd i stället är uttömd.

Om felet inte tydligt ligger i portalen skiljer Felsök autentiseringsfel på Sophos Firewall systematiskt nåbarhet, tjänsteval, Live Users, Main Group och den efterföljande trafikvägen åt.

För klassiska inloggningsförsök är access_server.log relevant. oauth_sso_captive.log behövs endast för SSO-processen med Microsoft Entra ID. Sophos Firewall-tjänsteloggar visar hur filerna läses utan att tjänster startas om för tidigt.

Inloggningen lyckas, men åtkomst saknas

En lyckad inloggning bekräftar bara autentiseringen. Därefter måste klientzon, källnätverk, grupp, destinationer, tjänster, regelposition, NAT och routing stämma överens med användarregeln. Log Viewer visar vilket Rule ID som faktiskt behandlar trafiken. För en systematisk kontroll, se Varför en Sophos Firewall-regel inte matchar.

Användaren loggas ut oväntat

Kontrollera valt sign-out-alternativ och dess tids- och datatrösklar, det öppna portalfönstret, viloläge, nätverksbyte och inaktivitet. Kontrollera även Maximum session timeout under Authentication > Services > Global settings samt Access Time, Surfing Quota och Network Traffic Quota. Med When captive portal page is closed or redirected avslutas kopplingen när keepalives uteblir. Det behöver inte synas exakt när fönstret stängs.

Inloggningen visas först efter ungefär två minuter

Om STAS används i samma nätverk kan dess inlärningsfas fördröja omdirigeringen. Kontrollera då först STAS-status och de oautentiserade klienterna. Den allmänna Captive Portal-processen ändrar inte något globalt CLI-värde för detta. Sambanden förklaras i STAS-artikeln.

Flera användare delar samma käll-IP-adress

Captive Portal kopplar i grunden användaridentiteten till en klient-IP-adress. IP-adresser som registrerats under Multi-user hosts för Per-Connection AD SSO via Direct Web Proxy kan därför inte använda Captive Portal. Per-Connection AD SSO för fleranvändarvärdar beskriver rätt procedur och den separata regeln utan Match known users för övrig trafik.

Vanliga frågor