Configurar Sophos Connect na Sophos Firewall

O Sophos Connect para IPsec Remote Access é configurado no SFOS 22 em Remote access VPN > IPsec. O túnel, por si só, não concede acesso: a autenticação, o endereçamento dos clientes, o DNS, as regras de firewall e o perfil distribuído têm de funcionar em conjunto.

Este artigo centra-se deliberadamente no lado da firewall. A instalação e a importação são descritas separadamente para Windows e macOS. Para SSL VPN, consulte Configurar Sophos Firewall SSL VPN Remote Access; se ainda não tiver decidido a arquitetura, consulte Sophos Connect ou SSL VPN.

Antes do primeiro clique

Para uma implementação controlada, são necessários:

• acesso administrativo ao WebAdmin e um endereço WAN acessível;
• utilizadores ou grupos numa origem suportada pelo Sophos Connect, como a base local, o Active Directory, RADIUS ou Microsoft Entra ID, bem como um conceito de MFA adequado;
• um pool privado livre para os clientes, as redes internas de destino e os serviços efetivamente necessários;
• servidores DNS capazes de resolver os nomes internos previstos e, se necessário, um sufixo DNS;
• um perfil IPsec IKEv1 e uma Preshared Key ou certificados RSA adequados;
• um acesso de teste externo, por exemplo através de um hotspot de rede móvel. O SFOS não suporta IPsec Remote Access a partir da zona LAN.

Ao atualizar para o SFOS 22.0 MR1 ou posterior, verifique primeiro se é necessário migrar o Legacy Remote Access IPsec.

Atribuir primeiro os serviços de autenticação

Em Authentication > Services, os servidores pretendidos têm de estar nos locais corretos em Selected authentication server:

• VPN portal authentication methods para o VPN Portal e o provisioning;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods para o início de sessão no túnel IPsec.

É habitual utilizar Local em conjunto com o servidor de diretório, RADIUS ou Entra ID configurado em Authentication > Servers. Teste esta atribuição antes de exportar. Com o Microsoft Entra ID SSO, o servidor Entra ID já tem de estar selecionado aqui antes de descarregar o ficheiro de configuração; caso contrário, o .scx não incluirá os valores de SSO. O procedimento completo encontra-se em Microsoft Entra ID SSO para VPN e a configuração de OTP em Configurar Sophos Firewall MFA.

Para SSO no Windows com Sophos Connect 2.4 ou posterior, distinga o firmware e o fornecedor: no SFOS 22, aplica-se o procedimento Entra ID indicado acima; o SFOS 23 disponibiliza OpenID Connect (OIDC) com um fornecedor de identidade (IdP) suportado. O Entra ID continua a ser uma opção válida. A configuração Google Workspace OIDC descreve a outra opção de fornecedor aqui abordada e os seus limites; isto não garante suporte para qualquer fornecedor OIDC, plataforma cliente ou build de firmware.

Também para um perfil importado diretamente, selecione o servidor IdP pretendido em Authentication > Services antes de descarregar a configuração. Com SSL VPN direto, o VPN Portal e SSL VPN têm de utilizar o mesmo servidor. Com IPsec direto, o túnel pode utilizar o mesmo servidor que o VPN Portal ou outro; isto não torna os fornecedores livremente intercambiáveis. A extensão OIDC para Windows não amplia o suporte Entra ID SSO no macOS descrito abaixo.

Requisitos do Entra ID na firewall

O SSO com Microsoft Entra ID para VPN de acesso remoto requer SFOS 21.5 ou posterior; nos Macs, é necessário Sophos Connect 2.1 ou posterior. A instalação do cliente e a configuração IPsec tradicional, por si só, não ativam SSO. Não sincronize utilizadores do mesmo domínio através de Active Directory e Microsoft Entra ID simultaneamente. Se já existir uma integração AD, verifique o mapeamento de utilizadores e grupos antes de configurar o Entra.

Em Microsoft Entra ID > App registrations, registe uma aplicação dedicada à firewall, de um único tenant, com a plataforma Web. Em API permissions, o Microsoft Graph requer as permissões delegadas User.Read.All e Group.Read.All; para importar grupos, é também necessária a permissão de aplicação Group.Read.All. Conceda consentimento de administrador. Crie um segredo de cliente em Certificates & secrets, copie imediatamente o seu valor para um local seguro e planeie a renovação antes de expirar. Introduza o ID de cliente, o ID de tenant e o segredo no servidor Microsoft Entra ID em Authentication > Servers e adicione à aplicação Entra os URI de redirecionamento gerados nessa página.

Configure MFA no fornecedor de identidade; a autenticação OTP da Sophos Firewall não é utilizada neste fluxo SSO. Nas Properties da Enterprise Application correspondente, defina Assignment required? como Yes e atribua utilizadores específicos para limitar quem pode iniciar sessão. Este requisito de atribuição não se aplica aos Global Administrators; teste a restrição com um utilizador normal. As políticas VPN e as regras da firewall continuam a determinar o acesso efetivo. Antes da implementação, siga o procedimento Entra completo indicado na ligação acima.

Definir endereços, destinos e caminho de reversão

Para evitar colisões, o pool VPN não pode sobrepor-se a LAN, WLAN, VLAN, VPN Site-to-Site ou redes domésticas comuns. O próprio SFOS exige que o intervalo se encontre numa sub-rede com, pelo menos, /24 e que não seja utilizado simultaneamente para SSL VPN, L2TP ou PPTP. Um exemplo é o intervalo de 10.250.10.10 a 10.250.10.200 dentro de 10.250.10.0/24.

Antes de qualquer alteração, documente o estado atual do IPsec, os certificados e IDs selecionados, a ordem das regras e as versões de .scx/.pro já distribuídas. Guarde o perfil antigo em segurança. Assim, uma alteração mal sucedida pode ser revertida repondo individualmente os valores e as regras, sem eliminar utilizadores, certificados ou outras configurações VPN existentes. Em contrapartida, Reset, no fim da página de IPsec, repõe a configuração de IPsec Remote Access de fábrica e não constitui um procedimento normal de reversão.

Configurar integralmente o IPsec Remote Access

As interfaces mais antigas e a captura de ecrã existente ainda mostram VPN > Sophos Connect Client. No SFOS 22, o caminho é Remote access VPN > IPsec.

General settings

1. Ative IPsec remote access.
2. Em Interface, selecione a porta WAN que servirá de ponto terminal do túnel. Nesta configuração de Remote Access, o SFOS disponibiliza exatamente uma interface WAN; vários gateways de provisioning não alteram esta associação do túnel.
3. Em IPsec profile, selecione um perfil IKEv1. Este só aparece se Dead Peer Detection estiver desativado ou definido como Disconnect. Os algoritmos de Phase 1 e Phase 2, DH/PFS e os tempos de vida têm de corresponder à norma de segurança. Algoritmos robustos e PFS são boas práticas recomendadas; as condições de IKEv1/DPD indicadas são, porém, requisitos do SFOS.
4. Defina Authentication type como Preshared key ou Digital certificate.
5. Preencha Local ID, Remote ID e Allowed users and groups.

Uma PSK é incluída na configuração exportada. Tem de ser aleatória e protegida e, em caso de suspeita, substituída em conjunto com os perfis afetados. A MFA protege adicionalmente o início de sessão do utilizador, mas não substitui esta chave do túnel.

Para Digital certificate, o SFOS 22 impõe limites claros:

• o IPsec utiliza certificados RSA, não ECDSA;
• Local Certificate e Remote Certificate precisam de uma Certificate ID;
• External certificate não pode estar selecionado;
• Local Certificate e Remote Certificate têm de pertencer à mesma cadeia de confiança. Utilize certificados gerados localmente ou certificados da mesma CA de terceiros e carregue a respetiva Signing CA na firewall.

A Sophos recomenda uma Local ID para identificar a firewall e uma Remote ID diferente para os clientes. São permitidos DNS, IP Address, Email e, no caso de certificados, DER ASN1 DN [X509]. Neste último caso, a firewall utiliza o Distinguished Name do certificado. Os IDs não têm de ser resolvidos publicamente, mas a firewall e o perfil exportado têm de esperar os mesmos valores.

Autorizar corretamente utilizadores e grupos

Em Allowed users and groups, inclua apenas as contas previstas. Para um utilizador de diretório, o IPsec Remote Access considera a Main group. Por conseguinte, o grupo AD autorizado tem de ser o seu grupo principal; caso contrário, autorize especificamente o utilizador em vez de abrir o acesso a um grupo abrangente.

Em Authentication > Groups, verifique a definição efetiva de IPsec remote access e a ordem dos grupos. Enquanto o IPsec Remote Access não estiver configurado, está desativado por predefinição para todos os grupos. Após a configuração, os grupos AD importados e os grupos migrados continuam desativados por predefinição; os novos grupos locais, por sua vez, estão ativos por predefinição. Se existirem vários grupos, aplica-se a política do grupo que estiver mais acima. As políticas individuais dos utilizadores têm, em regra, prioridade: por exemplo, um utilizador pode ser explicitamente autorizado mesmo que o acesso esteja desativado para o grupo. A exceção decisiva: se o IPsec Remote Access estiver explicitamente ativo para um grupo, não é possível bloquear esse acesso desativando-o individualmente para um membro. Ao remover o acesso de um utilizador, verifique, por isso, a atribuição efetiva de Main-group, a ordem dos grupos e todas as autorizações individuais ou de grupo, e retire a autorização efetiva em vez de confiar no interruptor do utilizador. Segundo a Sophos, desativar um grupo termina as respetivas sessões ativas e impede novas ligações; as autorizações individuais devem ser verificadas separadamente. Com um utilizador piloto normal, verifique a autenticação efetiva e os destinos permitidos e bloqueados. Ao remover o acesso de um utilizador, verifique as sessões ativas em Current activities > IPsec connections, utilize Disconnect de forma direcionada, se necessário, e confirme depois que o utilizador já não consegue autenticar-se nem aceder a destinos protegidos. Estas verificações são passos de validação, não efeitos comprovados aqui num dispositivo. Ligar o Active Directory à Sophos Firewall.

Regra geral, antes do primeiro início de sessão clássico no Sophos Connect, um utilizador AD tem de iniciar sessão noutro Authentication Client, como o User Portal. O provisioning pode criar a conta no primeiro início de sessão e atribuí-la com base no mapeamento do servidor. Guest users e guest groups não são permitidos para Remote Access.

Client information e Idle time

Em Client information, defina deliberadamente todos os campos:

• Name: um nome de apresentação curto e inequívoco, como remote-access-ipsec;
• Assign IP from: início e fim do pool privado previsto;
• Allow leasing IP address from RADIUS server for L2TP, PPTP, and IPsec remote access: ative apenas se o RADIUS atribuir os endereços. Se o RADIUS não fornecer um endereço, o SFOS utiliza primeiro um endereço estático configurado para o utilizador e, na falta deste, um endereço do intervalo Assign IP from;
• DNS server 1 e DNS server 2: resolvers responsáveis pelas zonas necessárias ou que encaminhem corretamente os pedidos para essas zonas.

Os resolvers públicos não são necessariamente inadequados, mas normalmente não resolvem zonas empresariais privadas sem publicação ou encaminhamento apropriados. Para recursos internos, teste por isso o caminho DNS efetivamente autoritativo ou de encaminhamento.

Em Idle time, pode ativar Disconnect when tunnel is idle. O valor de Idle session time interval é indicado em segundos. Trata-se de uma decisão operacional: um timeout curto reduz as sessões abandonadas, mas pode perturbar o trabalho e as novas ligações com MFA. Após uma desconexão por inatividade, o Sophos Connect tenta restabelecer a ligação em segundo plano; se não conseguir, selecione primeiro Disconnect e depois Connect no cliente.

Advanced settings

Estes valores são incluídos no .scx, mas não no .tgb:

• Use as default gateway: ativado para Full Tunnel, desativado para Split Tunnel. A escolha aplica-se a todos os utilizadores indicados em Allowed users and groups; não é possível definir comportamentos diferentes dentro da mesma configuração IPsec.
• Permitted network resources (IPv4): redes internas e hosts para o Split Tunnel. Inclua apenas o que os utilizadores devem alcançar através do túnel.
• Send Security Heartbeat through tunnel: enviar através do túnel o Heartbeat de um Sophos Endpoint existente.
• Allow users to save username and password: permitir apenas se a proteção dos dispositivos e os requisitos de MFA o admitirem. Para Connect tunnel automatically, a Sophos recomenda credenciais guardadas.
• Prompt users for 2FA token: apresentar um campo OTP separado. Ainda assim, a firewall transmite passwordotp; a MFA baseada em challenge não é suportada. O SCCLI não funciona com esta opção.
• Run AD logon script after connecting: executar o script de início de sessão do AD após estabelecer o túnel.
• Connect tunnel automatically: estabelecer automaticamente a ligação depois do início de sessão no dispositivo.
• Hostname or DNS suffix to monitor: introduzir um nome de host que apenas possa ser resolvido internamente ou um sufixo interno. O Sophos Connect utiliza-o para verificar a ligação automática; o host monitorizado tem de poder responder a sondas ICMP.
• Assign client DNS suffix: anexar um sufixo como firma.example ao adaptador de rede do dispositivo, para que nomes de host curtos sejam resolvidos como FQDN.

Com Split Tunnel, o SFOS cria ESP SAs separadas para as sub-redes permitidas e, em caso de inatividade, remove apenas a Child SA afetada. Com Full Tunnel, existe uma ESP SA, que é removida depois do intervalo de inatividade sem tráfego de dados.

Verificar a acessibilidade antes da firewall

Se a Sophos Firewall estiver atrás de um router ou de outro equipamento NAT, este tem de traduzir o endereço público para a interface WAN selecionada na firewall. Para NAT-T, é necessário permitir e encaminhar UDP 500 e UDP 4500. Se não existir NAT no percurso, o tráfego ESP utiliza o protocolo IP 50; nesse caso, o router a montante também tem de o deixar passar. Quando o SFOS deteta NAT, o NAT-T encapsula os restantes pacotes IKE e ESP através de UDP 4500.

Assim, uma verificação normal de portas TCP/UDP não comprova todo o percurso IPsec. CGNAT, NAT duplo ou uma rede de convidados restritiva também podem impedir o estabelecimento da ligação. Se o endereço público estiver diretamente no SFOS, não é necessária uma regra DNAT a montante.

Se a firewall estiver atrás de um router, guarde primeiro uma cópia segura da .scx exportada como perfil de origem. Segundo a FAQ da Sophos, altere manualmente o endereço de gateway na .scx para o endereço IP WAN do router. Distribua e volte a importar o perfil corrigido de forma controlada e teste depois o túnel e o tráfego permitido a partir de uma rede externa. Os encaminhamentos IKE/NAT-T continuam a ser necessários. Por outro lado, gateway em .pro aponta para o VPN Portal e não corrige automaticamente o endpoint do túnel na .scx; não se pressupõe aqui nenhuma chave de esquema não verificada.

Regras de firewall e Device Access

Acesso a destinos internos

Em Rules and policies > Firewall rules, crie uma regra IPv4 específica:

• Rule name: inequívoco, por exemplo VPN-SophosConnect-to-ERP;
• Rule position: acima de uma regra Drop mais genérica ou de uma regra Accept incompatível;
• Action: Accept;
• Log firewall traffic: ative para a validação e a operação;
• Source zones: VPN;
• Source networks and devices: o pool de clientes IPsec ou um objeto IP Host adequado, evitando Any sem necessidade;
• During scheduled time: All the time ou um período devidamente justificado;
• Destination zones: a zona efetivamente necessária, como LAN ou DMZ;
• Destination networks: apenas os servidores ou as redes autorizados;
• Services: apenas os protocolos e as portas necessários;
• Match known users e Users or groups: opcionalmente, como condição de identidade adicional, se for coerente com o conceito de autenticação.

O SFOS avalia as regras de cima para baixo e para na primeira correspondência. Depois de guardar, verifique por isso a posição efetiva; regras criadas automaticamente ou adicionadas posteriormente no topo podem alterar a ordem. Web, Application Control, IPS, Heartbeat e outras Security Policies não são um requisito geral do SFOS para tráfego VPN. Devem ser escolhidas em função da proteção necessária e testadas com as aplicações.

Full Tunnel para a Internet

Com Use as default gateway, também é necessário permitir tráfego de VPN para WAN:

Esta regra também deve utilizar o pool de clientes como Source network, os serviços adequados, logging e as políticas Web, Application Control ou IPS pretendidas. Além disso, o pool de clientes tem de ser abrangido por uma regra de SNAT/Masquerading adequada; uma regra NAT existente pode já cumprir esta função. É possível associar uma regra NAT, mas não é obrigatório. As regras NAT também são avaliadas por ordem, pelo que prevalece uma regra anterior e mais abrangente que corresponda ao tráfego. Um Full Tunnel sem políticas NAT e Security Policies coordenadas resulta frequentemente num túnel ativo sem acesso à Internet ou em tráfego não filtrado involuntariamente.

Local Service ACL

As regras de firewall controlam o tráfego encaminhado, não os serviços locais da firewall. Em Administration > Device access:

• permita IPsec a partir da zona WAN utilizada;
• permita VPN portal apenas a partir das zonas onde o download ou o provisioning são necessários; a Sophos recomenda que o acesso WAN seja apenas temporário;
• permita DNS a partir de VPN apenas se a própria firewall for utilizada como resolver DNS;
• permita Ping/Ping6 a partir de VPN apenas se a própria firewall for o destino dos testes.

Quando a autorização de toda uma zona for demasiado abrangente, uma Local service ACL exception rule pode limitar o acesso a hosts ou redes de origem específicos. Consulte Device Access e Local Service ACL para mais informações.

Exportar ou provisionar o perfil

Export connection cria um arquivo com .scx e .tgb. Para o Sophos Connect, .scx é o formato padrão e contém General Settings e Advanced Settings. O .tgb destina-se a clientes de terceiros compatíveis e contém apenas General Settings. Após alterações às General Settings ou Advanced Settings, a configuração tem de voltar a ser distribuída; se apenas as Advanced Settings forem alteradas, isto aplica-se somente ao .scx.

No Windows com Sophos Connect 2.1 ou posterior, um ficheiro .pro pode carregar a partir do VPN Portal as configurações IPsec e SSL VPN autorizadas e receber automaticamente alterações posteriores. A estrutura JSON exata, os vários gateways do portal, os campos de MFA e a distribuição por GPO são descritos em Provisionamento do Sophos Connect com .pro e GPO.

Para o SSO do Microsoft Entra ID com Sophos Connect para macOS a partir da versão 2.1, incluir também nos testes de aceitação a autenticação no browser aberto pelo cliente e o regresso ao cliente. O fluxo de autenticação no macOS com seleção do browser e alternativa em caso de falha explica os passos; depois, verificar o estado do túnel, o IP da VPN, o DNS e o acesso, sem enfraquecer o Conditional Access, a MFA ou as verificações de certificados. Se for necessário um ficheiro .pro personalizado para este fim, utilizar a sintaxe literal dos campos e os valores permitidos de sso_auth_browser_type indicados em Sophos Connect Provisioning.

No Sophos Connect 2.1 para macOS e em versões posteriores do cliente macOS, os valores permitidos para sso_auth_browser_type são auto, embedded e system. auto utiliza primeiro o navegador integrado e pode recorrer ao navegador do sistema. Para SSO com Entra ID, o VPN Portal tem de estar acessível através da zona WAN necessária em Administration > Device access; as restrições por Local Service ACL descritas acima continuam a ser importantes. Se o acesso ao portal for ativado apenas temporariamente e depois bloqueado, esta via de início de sessão SSO a partir do exterior deixa de estar disponível. vpn_portal_port é a porta real do VPN Portal, não a porta do túnel SSL VPN.

Importante para a resolução de problemas: gateway no .pro é o FQDN ou o endereço IPv4 da firewall através do qual o cliente acede ao VPN Portal e obtém as configurações. Não é automaticamente o gateway do túnel IPsec. O túnel termina na Interface selecionada em Remote access VPN > IPsec e registada no .scx carregado. Por conseguinte, vários gateways no .pro proporcionam vários caminhos de provisioning, mas não Multi-WAN para esta configuração individual de IPsec Remote Access.

Se o gateway ou a porta do VPN Portal mudar, é necessário adaptar o ficheiro .pro e distribuí-lo novamente. Se ambos permanecerem iguais, o método de provisionamento configurado pode voltar a obter a configuração VPN e as alterações posteriores. No caso de um ficheiro .scx importado manualmente, após alterações em General ou Advanced Settings, é necessário exportar novamente a ligação atual através de Export connection, distribuí-la por um canal seguro e voltar a importá-la no cliente. Update policy não substitui esta distribuição manual nem a nova importação; a utilização documentada diz respeito ao método de provisionamento, especificamente à alteração da porta ou do protocolo de SSL VPN. Uma atualização do software do cliente não atualiza automaticamente a política da firewall nem um perfil desatualizado; os perfis existentes continuam, em regra, a poder ser utilizados após uma simples atualização da versão do Sophos Connect. Guarde em segurança o perfil que se sabe funcionar e os valores correspondentes da firewall para uma reversão controlada. Antes da distribuição generalizada, verifique com um utilizador piloto normal a versão do perfil e o gateway do túnel, a autenticação/MFA, as rotas, o DNS e os destinos permitidos e bloqueados. Se a validação falhar, restaure em conjunto os valores anteriores da firewall e o perfil que se sabe funcionar, e repita as mesmas verificações.

Se o provisioning carregar valores antigos ou nenhuma configuração, verifique sucessivamente a acessibilidade e o certificado do VPN Portal, a porta do portal, o gateway, o início de sessão do utilizador e a MFA. Para o provisioning SSO, VPN portal authentication methods, VPN (IPsec/dial-in/L2TP/PPTP) authentication methods e SSL VPN authentication methods em Authentication > Services têm de utilizar o mesmo servidor IdP configurado: Entra ID no SFOS 22 ou um IdP OIDC suportado no SFOS 23 dentro do âmbito Windows definido acima. O gateway tem de corresponder ao FQDN ou endereço IPv4 da firewall indicado na secção Redirect URI desse servidor configurado em Authentication > Servers. Trata-se apenas do host, não do URI de callback completo com esquema, porta e caminho; introduza a porta do VPN Portal separadamente em vpn_portal_port. Continuam a aplicar-se as restrições específicas do fornecedor: para Google Workspace, utilize o FQDN válido exigido pelo guia detalhado, não um endereço IP. Antes da distribuição, compare as atribuições de servidor, o host e a porta do portal. Para erros SSO, siga o procedimento adequado ao firmware e ao fornecedor no artigo Entra ou Google indicado acima; não generalize os diagnósticos Entra para outros fornecedores OIDC.

Os perfis contêm informações relevantes para a segurança e devem ser distribuídos através de um canal protegido. Atribua nomes inequívocos às versões antigas e novas, para evitar que o helpdesk ou os utilizadores voltem inadvertidamente a uma versão anterior.

A distribuição de uma nova política da firewall não deve ser confundida com a atualização do software cliente. As versões, a aprovação em grupos-piloto e o planeamento da reversão são abordados em Atualizar o Sophos Connect em segurança.

Para a operação, documente o grupo VPN responsável e o processo de saída, o reset da MFA e o bloqueio e desbloqueio de utilizadores. A versão do perfil, a data da alteração e o responsável, os requisitos de logging permanente, incluindo Sophos Fusion (anteriormente Sophos Central) ou Syslog, bem como uma nova revisão dos perfis antes de upgrades do SFOS também devem fazer parte da documentação operacional.

Validação com um cliente remoto real

Após a importação, teste com um utilizador de destino normal a partir de uma rede externa:

1. O início de sessão e a MFA funcionam e o cliente recebe o endereço esperado do pool ou do RADIUS.
2. A sessão aparece em Current activities > IPsec connections. A lista pode ser filtrada, entre outros, por Connection name, Username, Local subnet e Remote host/subnet; Refresh atualiza a vista e Disconnect termina especificamente uma ligação.
3. Os FQDN internos e, se configurados, os nomes curtos através do sufixo DNS são resolvidos corretamente.
4. Os destinos permitidos funcionam e os restantes continuam bloqueados.
5. O Log Viewer mostra correspondências com a regra de firewall prevista.
6. O Split Tunnel mantém o restante tráfego de Internet local; o Full Tunnel encaminha-o através da firewall, da regra SNAT esperada e das Security Policies previstas.
7. A nova ligação funciona após o Idle Timeout, uma mudança de rede e um reinício do Endpoint.
8. No Sophos Connect Client, Events mostra a sequência cronológica da importação, do início de sessão e do estabelecimento do túnel. Perante um erro reproduzível, gere um Support report no cliente e guarde-o com a hora, o utilizador, a versão do cliente e a versão do perfil antes de alterar perfis ou certificados.

Para analisar as regras, consulte Testar uma regra de firewall com Log Viewer, Policy Test e Packet Capture. Para uma análise mais profunda do túnel, consulte Resolução de problemas de IPsec VPN na Sophos Firewall.

Resolução de problemas específica

Falha no início de sessão

Comece por verificar Authentication > Services, o estado da palavra-passe/MFA, os bloqueios e o servidor de autenticação independentemente da VPN. Em seguida, compare a Main group, Allowed users and groups e a opção de grupo IPsec remote access. O Sophos Connect apenas suporta caracteres ASCII nos nomes de utilizador; caracteres acentuados e outros caracteres UTF-8/UTF-16 podem impedir o início de sessão.

Em vez de basear o diagnóstico numa única mensagem de texto IKE sem documentação inequívoca, decomponha o processo: a tentativa chega à autenticação do utilizador? A Interface, o perfil IPsec, o certificado ou a PSK e as Local/Remote ID coincidem? O utilizador está realmente autorizado através da sua Main group? Os Events do cliente e os logs simultâneos da firewall fornecem dados mais fiáveis.

Failed to validate certificate após um reinício

Se a primeira ligação funcionar, mas após um reinício aparecer Failed to validate certificate, é frequente que Local Certificate e Remote Certificate não sejam assinados pela mesma CA. Verifique as Certificate IDs e a cadeia de confiança. Utilize certificados gerados localmente ou certificados da mesma CA de terceiros e carregue a respetiva Signing CA, ou mude deliberadamente para PSK. Depois, volte a exportar e importar o .scx e teste novamente após um reinício.

O túnel está ligado, mas não há tráfego

Verifique primeiro o endereço atribuído e as rotas no cliente e, depois, Permitted network resources, a posição da regra, Source/Destination networks, Services, o caminho de retorno e o DNS. Com Full Tunnel, verifique também a regra de VPN para WAN e a regra SNAT que efetivamente corresponde ao tráfego. Device access apenas intervém quando a própria firewall é o destino, por exemplo para DNS ou Ping.

A ligação cai aproximadamente a cada quatro horas

Durante o rekeying IKEv1, um novo pedido de OTP pode interromper o túnel. A Sophos indica um intervalo de rekeying de aproximadamente quatro horas para o perfil IPsec predefinido; um perfil personalizado pode utilizar até 24 horas. A avaliação de segurança e a implementação são explicadas em Resolver o timeout de IPsec Remote Access após quatro horas.

As transferências de grandes dimensões bloqueiam ou apenas algumas redes externas falham

Se o início de sessão, o DNS e os acessos de pequena dimensão funcionarem, mas as transferências maiores bloquearem, verifique MTU e MSS. Se o IPsec falhar apenas em hotéis, redes Wi-Fi de convidados ou redes empresariais com filtragem rigorosa, o acesso externo pode estar a bloquear UDP 500/4500 ou ESP. Nesse caso, SSL VPN ou outro modelo de Remote Access poderá ser mais robusto para estes utilizadores.

IPsec Remote Access após failover de HA

O erro NC-175860, documentado nas notas de versão do SFOS 22, afeta o IPsec Remote Access após um failover de HA se o Appliance Certificate tiver sido gerado novamente antes. Foi corrigido no SFOS 22.0 MR2 Build 546, de 14 de julho de 2026. A Sophos não indica uma mensagem de log específica nem um workaround oficial.

Antes de qualquer intervenção, registe o firmware e o build, o modo HA, as funções e Last status change de ambos os dispositivos, a hora do failover, o Authentication Type, os Local/Remote Certificate selecionados com as respetivas Certificate IDs e a versão do perfil. Não volte a gerar o Appliance Certificate apenas por suspeita. Numa versão anterior afetada, verifique o caminho de atualização aprovado para MR2 Build 546 ou posterior e, depois, teste numa janela de manutenção um failover controlado, incluindo o restabelecimento da ligação a partir do exterior. Os princípios da topologia são descritos em Variantes de cluster HA da Sophos Firewall e o processo de atualização em Atualização de firmware do SFOS.

FAQ