Configurar e testar o Sophos Firewall Captive Portal

O Captive Portal autentica utilizadores que já estão ligados a uma rede LAN ou WLAN. Em seguida, o Sophos Firewall pode associar o respetivo tráfego a uma identidade e aplicar regras a utilizadores ou grupos específicos.

O essencial é a interação entre os componentes: o portal cria a associação do utilizador, mas não concede por si só acesso à internet. Para isso, é necessária também uma regra de firewall adequada. O DNS, o routing, o NAT e a segmentação da rede têm de funcionar de forma independente.

O processo completo resume-se a seis passos:

1. Verificar a fonte de autenticação e o grupo autorizado.
2. Autorizar o Captive Portal para a zona dos clientes em Administration > Device access.
3. Se for utilizado um servidor DNS externo, criar uma regra DNS restrita sem associação a utilizadores.
4. Criar uma regra de utilizador com Match known users e Use web authentication for unknown users.
5. Em Authentication > Web authentication, definir HTTPS, a página de destino e o logout.
6. Verificar o login através da porta 8090, o utilizador em Live users e a Rule ID no Log Viewer.

O que o Captive Portal faz — e o que não faz

O Captive Portal é adequado para dispositivos BYOD, clientes não geridos ou redes onde não está disponível a identificação transparente dos utilizadores. O utilizador abre uma página web, é redirecionado para o login e fica depois associado ao respetivo endereço IP de origem na firewall. A firewall pode usar esta identidade como critério de correspondência.

Outros portais e métodos de autenticação resolvem tarefas diferentes:

• Um Wireless Hotspot destina-se ao acesso de convidados através de voucher, palavra-passe diária ou termos de utilização. O processo completo encontra-se em Configurar um Hotspot no Sophos Firewall.
• Um Guest user é uma conta local temporária para o Captive Portal. Criar e gerir utilizadores convidados em segurança explica grupo, validade, entrega de credenciais, autorregisto e limpeza.
• O VPN Portal faz parte do Remote Access. O Captive Portal não cria um túnel VPN e não deve ser utilizado como portal de login público.
• STAS, AD SSO ou SATC identificam, sempre que possível, os utilizadores sem login no browser. Nestes ambientes, o Captive Portal pode servir de alternativa para dispositivos onde a identificação transparente não funciona.
• Para um login Microsoft, aplica-se o procedimento separado Captive Portal com Microsoft Entra ID SSO.

A visão geral dos portais Sophos ajuda quando ainda não é clara a diferença entre User Portal, VPN Portal, WebAdmin e Captive Portal.

⚠️ O Captive Portal não substitui a segmentação. Uma rede BYOD ou de convidados permanece numa zona ou VLAN própria e recebe acesso apenas aos destinos e serviços realmente necessários. O login melhora a associação do utilizador, mas não torna automaticamente segura uma rede demasiado abrangente.

Pré-requisitos e exemplo

Antes da configuração, devem estar definidos os seguintes pontos:

• Uma fonte de autenticação local ou externa funciona. No caso do Active Directory, a ligação ao servidor e o grupo já foram verificados; a configuração é explicada em Ligar o Active Directory ao Sophos Firewall.
• São conhecidos a zona dos clientes, a rede de origem e o grupo de utilizadores autorizado.
• O cliente recebe um endereço IP correto, uma gateway e servidores DNS funcionais.
• Para o nome produtivo do portal existe um registo DNS e um certificado aceite pelos clientes.
• Uma regra MASQ/SNAT existente e o routing abrangem o tráfego de internet que será posteriormente autorizado.
• Estão disponíveis um utilizador de teste autorizado e outro não autorizado para a validação.

O exemplo utiliza:

• Zona dos clientes: LAN
• Rede dos clientes: 10.30.40.0/24
• Objeto de rede: BYOD_10.30.40.0_24
• IP da firewall na zona dos clientes: 10.30.40.1
• Grupo de utilizadores: BYOD_Internet
• Nome da regra: LAN-BYOD-to-WAN-Captive
• Servidor DNS interno: 10.20.0.53
• Nome do portal: login.example.com

Estes valores não devem ser copiados sem verificação. A zona e a rede têm de corresponder à interface real dos clientes, 10.30.40.1 deve ser substituído pelo IP da firewall nessa interface e o grupo tem de pertencer à fonte de autenticação utilizada. A partir da rede dos clientes, o nome do portal deve resolver exatamente para este endereço alcançável da firewall.

Configurar o Captive Portal passo a passo

1. Selecionar o método de autenticação

Em Authentication > Services, na secção Firewall authentication methods, definem-se as fontes que a firewall consulta durante um login. Pode ser a base de dados local de utilizadores ou um servidor AD, LDAP ou RADIUS previamente configurado. Criar e testar utilizadores locais normais descreve o grupo, a palavra-passe, Local, Sign-in Restriction e o ciclo de vida deste modelo. A ordem é relevante: se existirem vários servidores, o SFOS verifica-os de cima para baixo.

No exemplo, o grupo BYOD_Internet tem de existir na firewall. No caso do Active Directory, deve ser importado previamente. Só depois pode ser selecionado na regra de utilizador e atribuído de forma inequívoca durante o teste.

Uma ligação bem-sucedida ao servidor não é suficiente. Por isso, mais tarde é utilizado um login real no portal para verificar se a palavra-passe, o grupo e a regra de utilizador funcionam em conjunto.

2. Autorizar o Captive Portal para a zona de origem

Em Administration > Device access, na linha Captive portal, ative apenas as zonas a partir das quais os utilizadores devem realmente iniciar sessão. No exemplo, é LAN. Em seguida, guarde com Apply.

O Device Access controla o acesso a um serviço local da firewall. Uma regra LAN-to-WAN normal não substitui esta autorização. Por outro lado, o Captive Portal não deve ser aberto preventivamente para WAN ou para zonas internas não envolvidas. Device Access e Local Service ACL explica também o caso especial do Web Proxy, em que os portais locais podem ficar acessíveis apesar de uma tabela de zonas mais restrita.

Se os clientes utilizarem a própria firewall como resolver DNS, também é necessário autorizar DNS para a respetiva zona na mesma matriz. Com um servidor DNS separado, é necessária a regra de trânsito seguinte.

3. Disponibilizar o DNS antes do login

O browser só consegue abrir login.example.com ou a página originalmente solicitada se o DNS já funcionar antes da autenticação do utilizador. Se o servidor DNS não estiver na firewall, cria-se uma regra própria em 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: zona do servidor DNS
• Destination networks: objeto host para 10.20.0.53
• Services: DNS
• Log firewall traffic: ativar para a validação

Esta regra não tem associação a utilizadores, porque o cliente ainda não está autenticado. Antes do login, autoriza-se apenas o DNS para o resolver previsto, não tráfego arbitrário. Se o ambiente utilizar vários servidores DNS, os respetivos objetos host são adicionados de forma específica.

A regra DNS deve ser posicionada de modo que o resolver esteja acessível antes do login. No exemplo, fica imediatamente antes da regra de utilizador e acima de qualquer regra mais geral que rejeite ou processe de outra forma o DNS desta rede. Em seguida, guarde com Save.

Acima da tabela de regras, selecione o protocolo aplicável, IPv4 ou IPv6. Se os clientes só alcançarem o resolver através de IPv4, a regra DNS IPv4 é suficiente. Se o DNS também for utilizado através de IPv6, crie uma regra IPv6 igualmente restrita com os objetos de rede e host IPv6 adequados.

4. Criar a regra de utilizador

Agora é criada a regra de acesso propriamente dita. No exemplo, recebe os seguintes valores:

• 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: os destinos de internet necessários ou Any
• Services: apenas os serviços necessários
• Match known users: ativado
• Use web authentication for unknown users: ativado
• Users or groups: BYOD_Internet
• Log firewall traffic: ativado

Também aqui, selecione IPv4 ou IPv6 acima da tabela de regras. Numa rede dual-stack, crie uma regra de utilizador separada, com os objetos de rede adequados, para cada família de protocolos efetivamente autorizada; uma regra IPv4 não abrange IPv6.

Match known users torna a identidade num critério de correspondência. Use web authentication for unknown users faz com que um pedido web correspondente de um utilizador ainda não autenticado conduza ao login. O grupo determina quem pode utilizar a regra após uma autenticação bem-sucedida.

No SFOS 22 e 23, Use web authentication for unknown users não é o único mecanismo que desencadeia um login. Se a opção estiver ativada, um pedido web correspondente de um utilizador ainda não autenticado desencadeia a autenticação. Se estiver desativada, esta opção permite inicialmente o pedido sem login; no entanto, uma Web Policy atribuída pode continuar a bloqueá-lo e, assim, desencadear a autenticação web. O fator decisivo é saber se uma Web Policy para utilizadores ou grupos desconhecidos está definida como Block. O processo seguinte depende do AD SSO:

• Com AD SSO, tanto quando a regra desencadeia a autenticação como quando ocorre um Block pela Web Policy para utilizadores desconhecidos: o SFOS tenta primeiro o login transparente. Se este falhar, segue-se o redirecionamento para o Captive Portal. Após um login bem-sucedido, a página é recarregada e a Web Policy do utilizador é novamente avaliada.
• Sem AD SSO, com autenticação desencadeada pela regra: o pedido web correspondente de um utilizador ainda não autenticado é redirecionado diretamente para o Captive Portal.
• Sem AD SSO, apenas com bloqueio pela Web Policy: é apresentada uma página de bloqueio. Esta pode apresentar uma ligação ao Captive Portal; neste caso, não se deve esperar um redirecionamento automático como o desencadeado pela regra.

Para a ligação na página de bloqueio, existe uma opção própria na API XML: DisplayCaptivePortalLink em WebAuthentication / WebAuthenticationSettings; os valores de entrada permitidos são Enable e Disable. Não deve ser confundida com DisplayUserPortalLink, ou seja, Show user portal link: esta segunda opção apresenta na página do Captive Portal uma ligação ao User Portal. A descrição mais antiga da API descreve a primeira opção com Enable como um redirecionamento e com Disable como a apresentação de Access Denied. Isto não pode ser interpretado como uma opção universal de redirecionamento: a descrição da autenticação web para o SFOS 22 e 23 distingue expressamente os casos de regra, Web Policy e AD SSO acima referidos e, sem AD SSO, descreve uma página de bloqueio com uma ligação opcional ao portal quando o bloqueio resulta apenas da Web Policy. As descrições não coincidem no seu alcance geral; por isso, o valor da API, por si só, não garante um redirecionamento automático. Na verificação piloto seguinte, verifica-se também se a ligação prevista ao portal está visível no caso de página de bloqueio efetivamente aplicável.

Perante um login inesperado ou uma página de bloqueio, verificam-se primeiro, em conjunto, a regra que efetivamente correspondeu ao tráfego no Log Viewer, a opção nessa regra, a Web Policy para utilizadores ou grupos desconhecidos e o estado do AD SSO em Authentication > Web authentication. Antes de qualquer alteração, registam-se os valores existentes. A verificação é feita com um cliente piloto sem sessão existente e apenas para o acesso previsto para esse cliente: não se deve remover indiscriminadamente o Block, tornar as regras de utilizador menos restritivas ou alterar globalmente o AD SSO apenas para forçar um redirecionamento. Após o login, verificam-se Current activities > Live users, o utilizador e a Rule ID no Log Viewer, bem como um destino autorizado e outro que deve continuar bloqueado. Se o comportamento for inesperado, repõem-se os valores alterados e repetem-se as mesmas verificações.

Em Services, Any só é adequado se o grupo realmente tiver de receber acesso completo de cliente à internet depois do login. Para um acesso mais restrito, selecionam-se deliberadamente HTTP, HTTPS e outros protocolos necessários. O tráfego que não é web não consegue apresentar uma página de login; o utilizador tem de iniciar primeiro a autenticação num browser ou através do URL direto do portal.

A regra tem de ficar acima de uma regra allow abrangente baseada em IP. Caso contrário, o tráfego é processado antes e nunca chega à regra de utilizador. Depois de verificar a posição, guarde com Save. A avaliação básica é explicada em Planear corretamente as regras de firewall.

5. Definir HTTPS, redirecionamento e logout

Em Authentication > Web authentication não se ativa a acessibilidade do portal, mas configura-se o respetivo comportamento.

Se o AD SSO já estiver configurado, a escolha do mecanismo também faz parte da análise. Em Authentication > Web authentication, Kerberos & NTLM está documentado como a opção predefinida para o SFOS 22 e 23: ambos os mecanismos são disponibilizados nos cabeçalhos de autenticação e o browser escolhe um deles. NTLM only destina-se a clientes antigos que não conseguem processar cabeçalhos Kerberos. Na API XML, isto corresponde a UseKerberosForADSSO em WebAuthentication / WebAuthenticationSettings: Enable utiliza Kerberos em conjunto com NTLM, e Disable utiliza apenas NTLM. Não se deve desativar globalmente o Kerberos apenas para forçar um login no Captive Portal. Uma alteração justificada do mecanismo exige um plano de verificação próprio e de âmbito limitado: verificar primeiro a ligação existente ao AD, os pré-requisitos do Kerberos e os clientes afetados, guardar o valor anterior e verificar o login transparente e o recurso ao portal como alternativa com um cliente piloto. Se ocorrer uma regressão, repõe-se o valor guardado e repete-se a verificação; fora disso, a configuração existente do AD SSO permanece inalterada.

Captive Portal aceita no máximo 50 caracteres tanto para o nome de utilizador como para a palavra-passe. Este limite deve ser testado com uma conta real antes do rollout, sobretudo com diretórios externos e nomes de utilizador gerados automaticamente.

Numa configuração de produção, são importantes as seguintes decisões:

• Show user portal link apresenta na página do Captive Portal uma ligação ao User Portal. Ative-a apenas se os utilizadores precisarem realmente desse portal e este tiver de estar acessível a partir da respetiva zona.
• Use insecure HTTP instead of HTTPS permanece desativado. O HTTP transmitiria as credenciais sem encriptação. Com esta opção, o SFOS 22 não suporta Microsoft Entra ID SSO; no SFOS 23, esta restrição aplica-se ao OpenID Connect SSO no seu conjunto.
• Show web page after sign-in pode redirecionar o utilizador para a página originalmente solicitada ou para uma página interna definida.
• Open web page: In new browser window mantém a página do Captive Portal aberta para logout e keepalives. Se o mesmo separador for substituído, o processo de logout torna-se menos visível para o utilizador.
• When captive portal page is closed or redirected termina a sessão do utilizador quando a firewall deixa de receber keepalives. Isto também pode acontecer após a suspensão do dispositivo ou uma mudança de rede.
• When user is inactive avalia um período e a quantidade de dados transferidos nesse intervalo. O SFOS termina a sessão de um utilizador cujo tráfego fique abaixo do limiar configurado. Escolha o período e a quantidade para que o tráfego normal em segundo plano não mantenha indefinidamente todas as sessões obsoletas.
• Never exige logout manual e pode manter durante mais tempo associações desatualizadas entre utilizadores e endereços IP.

Não existe um timeout universalmente correto. Em dispositivos partilhados e com utilizadores alternados, as sessões mais curtas são mais importantes; em dispositivos atribuídos individualmente, o login pode ser menos intrusivo. Cada opção é testada com suspensão, mudança de WLAN e logout manual. Estas opções locais de sign-out não se aplicam ao Microsoft Entra ID SSO no SFOS 22 nem ao OpenID Connect SSO no seu conjunto no SFOS 23.

Antes da validação final, registam-se a versão do SFOS em utilização e o método de login. As opções locais de sign-out mencionadas não são um mecanismo adequado para evitar fins de sessão inesperados nestes logins SSO; esta exceção não permite concluir que a sessão seja ilimitada nem que exista um timeout específico do IdP. O teste SSO mantém-se em HTTPS com um certificado válido e fidedigno. O HTTP não é ativado, nem sequer para diagnóstico de erros. O login, a associação visível do utilizador e o logout são verificados com uma conta piloto no processo SSO efetivamente utilizado, em vez de se pressupor o efeito das opções locais de sign-out.

Além disso, Authentication > Services > Global settings > Maximum session timeout limita a duração total dos utilizadores autenticados. O SFOS verifica a autorização a cada três minutos; Access Policies, Surfing Quota e o limite de transferência de dados também podem terminar uma sessão. Este valor global afeta mais do que o Captive Portal, pelo que os outros métodos de autenticação devem ser verificados antes de o alterar.

Depois da seleção, guarde com Apply.

A Device Console contém também valores globais para as versões TLS mínimas do Captive Portal, X-Frame-Options e uma string de cifras partilhada com Web Proxy. Verificar em segurança as definições HTTP Proxy explica por que estes valores não são uma lista geral de tuning e como testar e reverter uma alteração com provas do portal e do proxy.

Em Captive portal appearance podem personalizar-se o logótipo, os textos e as cores. Se for utilizado Custom HTML em vez do layout predefinido, o marcador <div id="__loginbox"></div> e o bloco request-url indicado pela Sophos com o respetivo script de redirecionamento têm de permanecer inalterados e funcionais. Por isso, o HTML, CSS ou JavaScript próprio deve ser testado primeiro com Preview e depois com uma conta piloto. Um portal visualmente correto não é um sucesso se o template interromper o início de sessão, o redirecionamento ou o fim de sessão; Reset to default permite anular a personalização.

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

A parte do script deve ser colocada imediatamente antes de </body>.

A base de reposição e o layout ativo não são a mesma coisa. Na API XML, a operação Update default settings of captive portal, com o elemento DefaultCaptivePortal, altera os valores predefinidos que, segundo o comentário XML, são utilizados para Reset to default e para os campos que não podem ser personalizados através da interface normal. Isto deve ser distinguido da personalização ativa através de WebAuthentication / CaptivePortalAppearance. No exemplo dos valores predefinidos, além de rótulos e HTML, constam também DoNotClosePage, WillBeSignedOut, SigningIn e textos de validação dos dados introduzidos. São textos do portal, não opções que controlem o comportamento efetivo da sessão ou do logout. Se esta base de reposição tiver sido personalizada através da API, não se deve considerar Reset to default uma garantia de recuperação de um layout de fábrica inalterado. Também não é possível deduzir daí qualquer comportamento específico de um tenant.

O exemplo publicado dos valores predefinidos não é um modelo de substituição completo para automatização. Contém HTML input como marcador; além disso, EnterValidUsername aparece no exemplo XML, mas não na tabela de parâmetros, enquanto SsoSignedOut e CredentialLoginButtonLabel constam apenas da tabela. Isto não permite obter uma lista completa e fiável dos campos nem concluir que os campos omitidos permanecem inalterados quando se efetua uma alteração. Antes de uma intervenção deste tipo, guardam-se separadamente os valores predefinidos anteriores e a personalização ativa e define-se um procedimento de reversão adequado à versão para ambos. Se estes valores não estiverem disponíveis ou o procedimento de reversão não estiver claro, a alteração através da API não é efetuada; em particular, o botão de reposição não substitui a cópia de segurança dos valores predefinidos.

Para a operação dos valores predefinidos, a API documenta o estado da operação 200 com Operation Successful. e 500 com Operation Fail.. Para Web Authentication Settings, também são indicados 200 e 500; no entanto, a fonte estática não fornece aí um texto de resposta completo. São estados de operação documentados, não um estado HTTP medido neste contexto nem um XML de resposta completo que possa ser reproduzido. Mesmo um resultado de sucesso comunica apenas o resultado da operação de configuração, não um login funcional, o redirecionamento esperado ou um logout efetivo. Após uma alteração autorizada, continuam a ser necessários Preview e a verificação com uma conta piloto através de HTTPS com um certificado fidedigno: verificar o login, o redirecionamento, a associação do utilizador e o logout. Se ocorrer um erro, repõem-se os valores guardados da área efetivamente alterada e repetem-se as mesmas verificações.

6. Verificar o nome do portal e o certificado

O URL direto de diagnóstico é:

https://<Firewall-IP>:8090

No exemplo, pode abrir-se primeiro https://10.30.40.1:8090. Para produção, https://login.example.com:8090 é mais claro, desde que o nome resolva para a firewall e esteja incluído no certificado.

O endereço IP serve apenas para testar a acessibilidade. Se o certificado selecionado abranger apenas login.example.com, o browser apresenta, como esperado, um aviso de incompatibilidade de nome ao abrir 10.30.40.1. Não introduza credenciais depois de ignorar este aviso. Por isso, deve verificar-se sempre através do FQDN se o DNS e o certificado funcionam em conjunto.

Aceda a Administration > Admin and user settings. Antes da alteração, registe o valor atual de Redirect users e o Certificate selecionado. Em Admin console and end-user interaction, sob Redirect users, selecione depois Firewall’s configured hostname ou A different hostname; no exemplo, introduza login.example.com. Em Certificate, selecione o certificado que abrange esse nome. Utilize Check settings para testar o redirecionamento antes do rollout. A seleção do certificado não afeta apenas o Captive Portal, mas também outros portais locais da firewall. Depois da alteração, deve testar-se também o WebAdmin, o User Portal e o VPN Portal.

Se algum destes testes falhar, volte a selecionar o valor de redirecionamento registado e o certificado anterior e guarde com Apply. Em seguida, volte a testar o redirecionamento e os portais.

Um certificado publicamente fidedigno evita avisos em dispositivos não geridos. Com uma CA interna ou assinada pela firewall, a CA tem de estar instalada como fidedigna em todos os clientes. O nome do certificado, a cadeia completa e a atribuição segura são explicados em Gerir certificados no Sophos Firewall.

Para um certificado do portal assinado localmente pela CA Default da firewall, aceda a Certificates > Certificate authorities e selecione Download para Default. Extraia o certificado público da CA como ficheiro .pem do arquivo .tar.gz descarregado e distribua-o de forma controlada aos clientes previstos. No Windows, importe-o para Trusted Root Certification Authorities; nas outras plataformas, utilize o repositório equivalente de CA fidedignas. Confie apenas na CA verificada que realmente emitiu o certificado e nunca distribua uma chave privada da CA. Para um certificado do portal emitido por uma CA externa, deve estar presente na firewall a cadeia completa, incluindo os certificados intermédios. Em seguida, verifique o URL FQDN num cliente abrangido e confirme que não aparece qualquer aviso de certificado.

Testar completamente o login e a regra de utilizador

A validação começa com um cliente sem uma sessão existente. Em Current activities > Live users, pode terminar-se uma sessão de teste antiga, se necessário.

1. Verificar se o cliente recebeu um endereço de 10.30.40.0/24, a gateway prevista e o servidor DNS correto.
2. Abrir diretamente https://10.30.40.1:8090 para testar a acessibilidade do portal independentemente de um redirecionamento automático do browser. É esperado um aviso de nome se o certificado contiver apenas login.example.com. Em seguida, abrir o URL FQDN para validar o DNS e o certificado.
3. Sem uma sessão existente, abrir uma página HTTP normal e verificar o redirecionamento para o Captive Portal. Uma página HTTPS com comportamento HSTS guardado não é um teste fiável para este efeito.
4. Iniciar sessão com um utilizador autorizado. Se o Sophos MFA local estiver ativado, o token OTP tem de ser registado previamente no User Portal. A configuração é descrita em Ativar MFA no Sophos Firewall.
5. Em Current activities > Live users, verificar o nome do utilizador, o IP do cliente e o tipo de autenticação.
6. Testar uma página autorizada e, deliberadamente, um destino ou serviço não autorizado.
7. No Log Viewer, filtrar pelo IP do cliente. A entrada tem de mostrar o utilizador esperado e a Rule ID de LAN-BYOD-to-WAN-Captive.
8. Com um utilizador fora de BYOD_Internet, verificar que o login não concede acesso através desta regra.
9. Provocar o logout, a suspensão ou uma mudança de rede e verificar quando o utilizador desaparece de Live users.

Numa rede dual-stack, o teste é realizado separadamente para IPv4 e IPv6. O SFOS mantém as duas associações de utilizador em separado e ambas as variantes exigem regras de firewall adequadas; por isso, um teste IPv4 bem-sucedido ainda não confirma que o acesso IPv6 funciona. Os utilizadores têm de iniciar sessão separadamente para aceder a páginas IPv4 e IPv6; um segundo pedido de login não indica, por isso, automaticamente um erro.

Diagnosticar de forma dirigida os erros típicos

O portal não aparece

Começar por abrir o URL direto na porta 8090. Se não estiver acessível, verificar a zona de origem e Captive portal em Device Access, o IP do cliente, o mapeamento da zona, o DNS e o FQDN do portal.

Se o URL direto estiver acessível, mas o login automático não aparecer, o tráfego é frequentemente processado primeiro por uma regra mais geral ou falta a opção Use web authentication for unknown users. Além disso, apenas um pedido web correspondente consegue iniciar o login no browser. As aplicações que não utilizam a web não mostram uma página do Captive Portal.

O login é rejeitado

Em Authentication > Services, verificar a fonte de autenticação e a ordem. Em seguida, verificar a ligação ao servidor, a palavra-passe, o grupo de utilizadores, a quota e, no caso de MFA local, se o registo OTP foi concluído. Os horários recorrentes permitidos ou bloqueados são verificados separadamente com Access Time para utilizadores e grupos. O procedimento de Surfing Quota e Network Traffic Quota mostra se, em vez disso, foi esgotado o tempo de Internet ou o volume de dados consumido.

Se o erro não estiver claramente no portal, Resolver sistematicamente erros de autenticação na Sophos Firewall separa a acessibilidade, seleção do serviço, Live Users, Main Group e percurso posterior do tráfego.

Para tentativas de login clássicas, é relevante o ficheiro access_server.log. O ficheiro oauth_sso_captive.log só é necessário para o processo SSO com Microsoft Entra ID. Logs de serviços do Sophos Firewall explica como ler os ficheiros sem reiniciar serviços prematuramente.

Login bem-sucedido, mas sem acesso

Um login bem-sucedido confirma apenas a autenticação. Depois, a zona dos clientes, a rede de origem, o grupo, os destinos, os serviços, a posição da regra, o NAT e o routing têm de corresponder à regra de utilizador. O Log Viewer mostra qual Rule ID processa efetivamente o tráfego. Para uma verificação sistemática, consulte Porque não corresponde uma regra do Sophos Firewall.

O utilizador é desligado inesperadamente

Verificar a opção de sign-out selecionada e os respetivos limiares de tempo e dados, a janela do portal aberta, a suspensão, as mudanças de rede e a inatividade. Verificar também Maximum session timeout em Authentication > Services > Global settings, bem como Access Time, Surfing Quota e Network Traffic Quota. Com When captive portal page is closed or redirected, a associação termina depois de deixarem de chegar keepalives; isto não tem de ser visível exatamente no momento em que a janela é fechada.

O login só aparece após cerca de dois minutos

Se o STAS for utilizado na mesma rede, a respetiva fase de aprendizagem pode atrasar o redirecionamento. Nesse caso, verificar primeiro o estado do STAS e os clientes não autenticados. O processo geral do Captive Portal não altera nenhum valor CLI global para este efeito; as relações são explicadas no artigo sobre STAS.

Vários utilizadores partilham o mesmo IP de origem

O Captive Portal associa, por princípio, a identidade do utilizador a um endereço IP do cliente. Por isso, os endereços IP registados em Multi-user hosts para Per-Connection AD SSO através do Direct Web Proxy não podem utilizar o Captive Portal. Per-Connection AD SSO para hosts multiutilizador explica o procedimento adequado e a regra separada sem Match known users para o restante tráfego.

Perguntas frequentes