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.

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

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.

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.

Följande val är viktiga i en produktionskonfiguration:

• Use insecure HTTP instead of HTTPS ska förbli avaktiverat. HTTP skulle överföra inloggningsuppgifterna okrypterat och fungerar inte med Entra ID SSO.
• 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 passar bättre om en session ska avslutas efter en definierad inaktivitetsperiod.
• 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å personliga enheter kan inloggningen få vara mindre störande. Varje val ska testas med viloläge, WLAN-byte och manuell utloggning. Dessa lokala sign-out-alternativ gäller inte för Entra ID SSO.

Spara valet med Apply.

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. Kontrollera därför alltid via FQDN att DNS och certifikatet fungerar tillsammans.

Inställningarna finns under Administration > Admin and user settings > Admin console and end-user interaction. Under Redirect users väljs Firewall’s configured hostname eller A different hostname. För exemplet anges login.example.com. Under Certificate väljs certifikatet som omfattar namnet. Certifikatvalet påverkar inte bara Captive Portal utan även andra lokala brandväggsportaler. Testa därför även WebAdmin, User Portal och VPN Portal före en ändring.

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.

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. Ett lyckat IPv4-test visar därför inte att IPv6-åtkomsten fungerar.

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, det öppna portalfönstret, viloläge, nätverksbyte och inaktivitet. 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