Configurar o acesso remoto SSL VPN no Sophos Firewall

O acesso remoto SSL VPN é configurado no Sophos Firewall em Remote access VPN > SSL VPN. Para que o acesso seja seguro, seis componentes precisam estar alinhados:

Atribuir utilizadores ou grupos a uma política SSL VPN.
Configurar globalmente o protocolo, o certificado, o gateway, o intervalo de endereços e o DNS.
Escolher de forma consciente entre Split Tunnel e Use as default gateway.
Permitir o tráfego da zona VPN com regras de firewall restritivas.
Proteger VPN Portal, autenticação, MFA e Device Access.
Distribuir um perfil .ovpn atualizado ou, no Windows, um ficheiro de provisioning .pro, e testar acessos permitidos e negados.

⚠️ SSL VPN é um ponto de entrada acessível publicamente. MFA e senhas fortes não substituem grupos de utilizadores restritos, Local Service ACLs, regras de firewall, perfis atualizados, logs e revisões periódicas.

Este artigo aborda a configuração do firewall. A instalação é descrita separadamente para Windows, macOS, iPhone e iPad, Android e Linux. Para a decisão prévia entre SSL VPN, IPsec e ZTNA, consulte Sophos Connect ou SSL VPN.

Preparar os requisitos e os objetos

Antes da configuração, é preciso definir o acesso público, os utilizadores autorizados e os destinos internos:

uma versão atual do SFOS e um cliente Sophos Connect atualizado;
um FQDN público ou endereço IP público;
certificados para o túnel SSL VPN e VPN Portal;
utilizadores ou grupos e servidores de autenticação;
um método MFA para o portal e o túnel;
um intervalo de endereços SSL VPN que não se sobreponha a outras redes;
redes internas de destino, servidores DNS e domínio de pesquisa;
a escolha entre Split Tunnel e Full Tunnel;
um processo para distribuir perfis e atualizar clientes.

Os destinos internos são criados primeiro como hosts ou objetos de rede:

Hosts and services > IP host

O exemplo a seguir utiliza:

LAN_Server: 10.10.10.0/24 para servidores internos;
LAN_Client: 10.10.20.0/24, caso os utilizadores remotos realmente precisem dessa rede de clientes;
DNS_Internal: 10.10.10.10 para o DNS interno ou o controlador de domínio;
SSLVPN_Users: grupo de utilizadores para Policy members.

Não se deve liberar redes internas inteiras quando bastam servidores ou sub-redes específicos. Os servidores DNS também precisam de um objeto claramente definido para que a rota e a regra de firewall possam ser compreendidas posteriormente.

Configurar os ajustes globais de SSL VPN

Os ajustes globais se aplicam a todas as políticas de acesso remoto SSL VPN e fazem parte da configuração .ovpn:

Remote access VPN > SSL VPN > SSL VPN global settings

Estes valores também são utilizados por ligações SSL Site-to-Site entre duas Sophos Firewalls. Por isso, quem alterar a porta, o protocolo, o certificado ou Override hostname deve verificar tanto os perfis de Remote Access como os túneis SSL Site-to-Site existentes e voltar a distribuir a respetiva configuração.

Antes de alterar valores globais do perfil, documente Protocol, Port, Override hostname, SSL server certificate, os valores de lease e DNS e a configuração dos pares SSL Site-to-Site afetados. Inclua também qualquer NAT ou reencaminhamento de portas a montante no plano de reversão. Se o teste de aceitação falhar, restaure esses valores e a configuração Site-to-Site anterior e repita com o perfil antigo os testes do portal, do túnel e dos acessos permitidos e negados.

Protocolo, certificados, gateway e porta

SSL VPN oferece suporte a TCP e UDP. O UDP geralmente é a opção inicial mais eficiente; o TCP pode ser uma alternativa testada quando redes externas bloqueiam UDP. A escolha deve ser verificada em redes reais de hotéis, operadoras móveis ou convidados.

A porta padrão do SSL VPN é 8443, enquanto VPN Portal usa 443 por padrão. Para cada serviço acessível publicamente, uma combinação exclusiva de IP WAN, porta e protocolo é a opção mais simples de compreender.

A Sophos utiliza dois certificados distintos:

O SSL server certificate selecionado nos ajustes globais de SSL VPN é utilizado pelo servidor SSL VPN.
O certificado HTTPS de VPN Portal é selecionado em Administration > Admin and user settings.

Os dois certificados devem corresponder ao FQDN público utilizado em cada caso. Com certificados de uma CA externa, a cadeia de certificados necessária também deve estar disponível.

Override hostname determina o FQDN ou o endereço IP público no perfil do cliente. Isso é especialmente importante quando há NAT upstream, várias interfaces WAN ou DDNS. Se o campo ficar vazio, o perfil poderá conter vários endereços de interface. O Sophos Connect prioriza gateways DDNS e tenta outras entradas em ordem inversa; por isso, um FQDN exclusivo é mais fácil de testar e administrar.

VPN Portal e SSL VPN podem partilhar tecnicamente a mesma porta e o mesmo protocolo. Nesse caso, porém, as configurações de Login Security não funcionam como esperado, e VPN Portal fica acessível a partir das zonas ativadas para SSL VPN. O WAF deve ser diferente de VPN Portal no IP WAN ou na porta, e diferente de SSL VPN no IP WAN, na porta ou no protocolo. Sophos Firewall WAF explica outras dependências do WAF.

Intervalo de endereços e DNS

O intervalo de endereços IPv4 deve ser privado e não pode se sobrepor a redes internas, VPNs site-to-site, rotas estáticas, outros pools de acesso remoto nem redes domésticas comuns. São especialmente frequentes 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 10.0.0.0/24 e 10.0.1.0/24.

A documentação do SFOS 22 é contraditória quanto ao prefixo permitido para pools IPv4 menores. A ajuda do campo indica /24 como limite e afirma que sub-redes /25 ou menores não podem ser selecionadas, enquanto a FAQ atual também descreve sub-redes menores distribuídas internamente por várias instâncias OpenVPN. Por isso, prevalece a versão do SFOS utilizada: verifique que prefixo a interface oferece e confirme depois o número real de leases disponíveis.

Segundo a FAQ da Sophos, o número de instâncias SSL VPN simultâneas depende dos CPU do modelo de firewall. Cada instância cria uma interface tun0 e necessita de uma sub-rede própria para routing e distribuição interna. A SFOS divide o pool configurado; estas necessidades de endereços surgem antes da atribuição de leases aos clientes. Como ilustração, a FAQ apresenta 192.168.0.0/27, oito instâncias simultâneas e apenas um endereço IP restante disponível para lease. Não é uma capacidade universal nem uma rede de exemplo recomendada: verifique os leases reais no build e modelo de destino; o conflito entre a ajuda do campo e a FAQ descrito acima mantém-se.

SFOS 23: O intervalo IPv4 selecionável depende do modelo de firewall; os modelos maiores suportam sub-redes com mais endereços IP. A ajuda do SFOS 23 indica /24 como a menor sub-rede selecionável. É um limite de seleção dependente do modelo, não uma garantia de um número específico de leases para clientes. A divisão interna dependente dos CPU explica o consumo de endereços, mas não os intervalos de seleção suportados. Isto não resolve o conflito do SFOS 22 nem transforma a ilustração /27 numa recomendação de configuração.

Antes de alterar o intervalo, registe o build do SFOS, o modelo, o intervalo anterior e as atribuições estáticas, e conserve os valores anteriores para reversão. Selecione na interface apenas um intervalo suportado pelo modelo de destino, mantenha os endereços estáticos dos utilizadores dentro do intervalo estático resultante e verifique os leases realmente disponíveis. Depois, volte a ligar um utilizador piloto e teste o lease, DNS e destinos permitidos e bloqueados. Se a aceitação falhar, restaure os valores e atribuições anteriores e repita os testes. Se o build, a interface, a ajuda ou a FAQ se contradisserem, pare a expansão de capacidade que dependa destes dados até esclarecer com o suporte; não force uma máscara.

API XML do SFOS 23 – estado 551: A linha de estado em bruto de Configure SSLVPN Tunnel Access remete para o identificador de execução não resolvido Message.SSLVPNInvalidLeaseIPv4Mask. Não permite deduzir um texto de mensagem confirmado, uma causa de rejeição estabelecida ou um novo intervalo de máscaras suportado. Se a API devolver 551, conserve a resposta completa e as definições anteriores. Antes de qualquer alteração, verifique StartIP, SubnetMask e a seleção de pool suportada pelo build instalado e pelo modelo, recorrendo à ajuda aprovada para esse ambiente ou ao Sophos Support; não force uma máscara.

Após uma correção suportada, verifique a resposta da API, as definições efetivamente guardadas na firewall de destino e a lease de um utilizador piloto que tenha voltado a ligar-se. Conserve os valores e atribuições anteriores para a reversão descrita acima. Se o diagnóstico ou o texto da mensagem continuarem a ser relevantes para a aprovação e não estiverem esclarecidos, mantenha a implementação pendente.

Um pool pequeno não constitui um controlo de acesso; para isso servem a política e as regras de firewall. Nas regras, são utilizados os hosts de sistema ##ALL_SSLVPN_RW e, para IPv6, ##ALL_SSLVPN_RW6.

Os servidores DNS internos são inseridos em IPv4 DNS. Domain name contém o domínio de pesquisa anexado a nomes de host curtos. Com Split Tunnel, o servidor DNS ou sua rede também deve constar em Permitted network resources e ser acessível por uma regra de firewall a partir da zona VPN. Com Full Tunnel, a rota específica de Split Tunnel deixa de ser necessária, mas a regra de firewall continua sendo exigida.

Se o próprio firewall atuar como resolver DNS, insira o endereço apropriado dele em IPv4 DNS. Além disso, permita DNS para a zona VPN em Administration > Device access. Um teste pelo endereço IP e outro separado pelo nome do host permitem distinguir um problema de roteamento de um problema de DNS.

IPs estáticos, sessões simultâneas e tempos

Endereços IP SSL VPN estáticos são possíveis em casos especiais justificados, como uma liberação legada baseada em IP, e devem estar dentro do pool configurado. No entanto, um utilizador com um endereço IP SSL VPN estático não pode estabelecer várias sessões simultâneas de acesso remoto.

Independentemente disso, Simultaneous logins, em Authentication > Services ou diretamente no utilizador local, limita os logins simultâneos. O valor global se aplica apenas aos utilizadores criados posteriormente.

Key lifetime controla o momento do rekey e não representa um timeout de inatividade nem uma duração máxima da sessão. As conexões inativas são tratadas pelos ajustes globais de inatividade e, opcionalmente, por Disconnect idle clients na política. Em caso de desconexões inesperadas, esses valores, a atribuição de IP estático, os logins simultâneos e os logs devem ser verificados separadamente.

Disconnect dead peer after é um valor global em segundos e encerra as ligações de clientes que não respondem. Os valores predefinidos são 180 segundos para TCP e 100 segundos para UDP; para UDP, o SFOS aceita valores de 60 a 110. Disconnect idle peer after, pelo contrário, é especificado em minutos e encerra sessões efetivamente inativas. Antes de aumentar um valor, utilizar sslvpn.log, o log do cliente e dados de perda de pacotes para determinar qual temporizador é realmente acionado.

O Override global timeout de uma policy só pode reduzir o valor global de inatividade. Se o valor da policy for superior, continua a aplicar-se o valor global. Uma página antiga de troubleshooting da Sophos recomenda um valor superior na policy para utilizadores individuais, mas a ajuda de campos atual do SFOS 22 contradiz expressamente essa indicação. Para permitir sessões mais longas, não aumentar inutilmente o valor na policy; ajustar o valor global após uma avaliação de impacto e repetir o teste com o mesmo grupo de utilizadores.

Criar a política SSL VPN

A política é criada manualmente ou pelo assistente:

Remote access VPN > SSL VPN

A Sophos recomenda o assistente especialmente para a primeira política SSL VPN. Este mostra os ajustes globais apenas para revisão e não permite alterá-los. Aplica os servidores e métodos de autenticação selecionados, configura Device Access para VPN Portal e SSL VPN e cria a política e a regra de firewall. Na primeira utilização, cria o grupo de regras Automatic VPN rules no início da tabela de regras e ativa a nova regra. As regras posteriores do assistente são colocadas no final desse grupo. Após cada execução, verifique a posição e a Rule ID que realmente corresponde. Em ambientes existentes, Configure manually geralmente é mais transparente:

Selecionar Add > Configure manually.
Inserir, por exemplo, SSLVPN-Remote-Users em Name.
Selecionar o grupo SSLVPN_Users em Policy members.
Definir Split Tunnel ou Use as default gateway.
Com Split Tunnel, selecionar LAN_Server e DNS_Internal como Permitted network resources. Use objetos de rede ou de host, não interfaces: selecionar uma interface não garante acesso à sub-rede correspondente.
Configurar opcionalmente Disconnect idle clients e Override global timeout.
Guardar e verificar a configuração com um membro comum do grupo de destino.

Utilizadores e grupos convidados não podem ser usados como Policy members. Se um utilizador ou grupo já estiver incluído numa política SSL VPN anterior, o SFOS removerá essa atribuição da política anterior. Por isso, as sobreposições devem ser verificadas antes de guardar.

Um Override global timeout específico da política só se aplica quando é menor que o valor global de inatividade. Um valor maior não substitui o limite global.

Split Tunnel ou Full Tunnel

Com Split Tunnel, somente as redes IPv4 e IPv6 e os destinos FQDN compatíveis selecionados em Permitted network resources são roteados pela VPN. Os destinos FQDN são compatíveis apenas com IPv4. O restante do tráfego de Internet permanece local. Isso reduz a carga do firewall e a latência, mas exige um planejamento preciso de recursos e DNS.

Quando o endereço IP de um destino FQDN permitido muda, os túneis existentes não são atualizados automaticamente. Os utilizadores afetados precisam desconectar e reconectar.

Com Full Tunnel, Use as default gateway é ativado. Todo o tráfego do utilizador passa pelo firewall. Permitted network resources não é aplicado como limite de acesso. Destinos e serviços internos devem ser limitados por regras de firewall; o acesso IPv4 à Internet também requer uma regra SNAT/MASQ adequada.

Full Tunnel permite o controle centralizado de web, DNS e logs, mas aumenta o consumo de banda, a carga do firewall e o trabalho relacionado à privacidade e ao suporte. Por isso, deve ser testado com aplicações reais e utilizadores simultâneos.

Regras de firewall, Device Access e autenticação

Regras de firewall e DNS

O estabelecimento do túnel ainda não permite o acesso aos recursos internos. Para isso, é criada uma regra:

Rules and policies > Firewall rules

Exemplo para Split Tunnel:

Rule name: VPN_SSLVPN_to_Internal_Servers
Action: Accept
Source zone: VPN
Source networks and devices: ##ALL_SSLVPN_RW
Destination zones: LAN
Destination networks: LAN_Server, DNS_Internal
Services: somente os serviços de aplicação necessários e DNS
Log firewall traffic: ativado

A regra deve ficar acima de regras VPN mais abrangentes. Um teste negativo para um destino não permitido mostra se uma regra geral posicionada abaixo concede acesso involuntariamente.

Para IPv4 Full Tunnel, são adicionadas uma regra de VPN para WAN e uma regra SNAT/MASQ adequada. O IPv6 requer roteamento IPv6 planejado e regras de firewall IPv6 próprias. Se o acesso falhar, Log Viewer, Rule ID e o guia para testar regras de firewall ajudam no diagnóstico.

VPN Portal, Device Access e MFA

O portal, os serviços locais e a autenticação são verificados em locais diferentes:

Administration > Admin and user settings
Administration > Device access
Authentication > Services
Authentication > Multi-factor Authentication

São necessários, no mínimo:

SSL VPN nas zonas a partir das quais o túnel poderá ser estabelecido;
VPN Portal somente nas zonas realmente necessárias;
DNS na zona VPN apenas quando o firewall atuar como resolver;
VPN portal authentication methods adequados;
SSL VPN authentication methods adequados;
MFA para o portal e o túnel.

Quando um método de autenticação contém vários servidores, o SFOS envia-lhes os pedidos pela ordem apresentada. Cada método permite selecionar no máximo 20 servidores. Quando existirem nomes de utilizador idênticos ou um mecanismo de reversão, verifique qual servidor processa efetivamente o pedido.

As regras de firewall normais não controlam esses serviços locais. Redes de origem mais restritas, endereços IP individuais ou países são configurados por meio de Local Service ACL Exception Rules. O processo completo de proteção é descrito em Device Access e Local Service ACL.

O web proxy do firewall é um caso especial: os pedidos HTTP e HTTPS que passam por ele são tratados como internos para os serviços locais. Assim, os utilizadores com acesso ao proxy podem aceder a VPN Portal mesmo que este não esteja ativado para a zona de origem. Ao usar o proxy, teste essa disponibilidade separadamente em vez de confiar apenas na matriz de zonas em Device Access.

Third-party Threat Feeds também podem bloquear acessos direcionados ao próprio sistema e aos serviços VPN. Isso permite bloquear adicionalmente origens indesejadas conhecidas; Threat Feeds no Sophos Firewall explica a configuração e os limites.

VPN portal authentication methods controla o início de sessão no portal e o download do perfil, enquanto SSL VPN authentication methods controla o início de sessão no túnel. WebAdmin é uma interface administrativa separada e não precisa de ser ativada na zona WAN para usar SSL VPN.

SSO por versão do SFOS: No SFOS 22, configure Microsoft Entra ID com Server type: Microsoft Entra ID SSO. No SFOS 23, abra Authentication > Servers > Add, selecione Server type: OpenID Connect e depois IdP vendor: Microsoft Entra ID ou IdP vendor: Google Workspace. A configuração da aplicação, servidor, Redirect URIs e grupos é descrita, respetivamente, em Microsoft Entra ID SSO para Sophos Connect e Google Workspace OIDC no Sophos Firewall. Estas variantes não confirmam a disponibilidade GA de um build.

Antes de descarregar o perfil, selecione o mesmo servidor IdP configurado em Authentication > Services para VPN portal authentication methods e SSL VPN authentication methods, e clique em Apply para cada serviço; no SFOS 22, trata-se do mesmo servidor Entra. Compare a Redirect URI completa no fornecedor escolhido, incluindo FQDN, porta e caminho, e verifique os endpoints de início de sessão necessários. Um SSO bem-sucedido não substitui a pertença a grupos, Policy members nem regras de firewall restritas. Antes da mudança, conserve as atribuições de serviços, a ordem dos servidores e os perfis funcionais. Após alterações SSO, descarregue e importe novamente a configuração atual e teste com um utilizador piloto normal o portal, túnel, MFA do IdP, DNS e destinos permitidos e bloqueados. Em caso de erro, restaure as atribuições, ordem e perfis correspondentes registados e repita os mesmos testes; não remova o acesso anterior antes da aceitação bem-sucedida.

Para o OTP nativo do SFOS, selecione os utilizadores ou grupos de destino em Authentication > Multi-factor authentication e ative VPN portal e SSL VPN remote access em Require MFA for. Com Generate OTP token with next sign-in, o utilizador deve primeiro digitalizar o código QR em VPN Portal; só depois poderá começar o teste do túnel.

VPN Portal não oferece suporte à autenticação RADIUS com Challenge MFA. O Sophos Connect também não oferece suporte a um challenge OTP, mas envia a senha e o OTP juntos; os métodos Call e Push são compatíveis. O método escolhido deve ser testado com um utilizador piloto comum. Consulte MFA para Sophos Firewall para obter mais informações.

Distribuir e atualizar o perfil do cliente

Se forem alterados valores globais relevantes para o perfil, como o protocolo, a porta, a interface, o certificado do servidor ou Override hostname, descarregue novamente o ficheiro .ovpn atual do VPN Portal, distribua-o de forma segura e, em caso de implementação manual, volte a importá-lo no cliente. Update policy não é aqui o primeiro passo nem substitui a nova importação manual. A utilização documentada diz respeito a uma ligação provisionada através de .pro: após alterar a porta ou o protocolo de SSL VPN, execute Update policy nessa ligação; este método de provisionamento obtém automaticamente outras alterações de configuração. Alterações, por exemplo, à porta, ao gateway, ao certificado do servidor ou ao protocolo podem exigir um novo início de sessão. Uma atualização do software Sophos Connect não substitui um perfil desatualizado. Guarde em segurança o perfil que se sabe funcionar e os valores globais correspondentes da firewall para uma reversão; antes da distribuição generalizada, verifique a nova importação com um utilizador piloto normal quanto ao gateway/porta, à autenticação/MFA, às rotas, ao DNS e aos destinos permitidos e bloqueados. Se a validação falhar, restaure em conjunto os valores anteriores e o perfil que se sabe funcionar, e repita as mesmas verificações.

Após uma alteração em Override hostname ou na porta, deve-se verificar no cliente se o perfil recém-importado realmente utiliza o novo nome do gateway e a nova porta.

Após mudanças em Policy members, Permitted network resources ou no endereço IP de um destino FQDN, normalmente basta desconectar e reconectar. As redes permitidas não são armazenadas estaticamente no ficheiro .ovpn; o SFOS adiciona os recursos específicos do utilizador quando o túnel é estabelecido. Portanto, essas alterações não exigem um novo download do ficheiro .ovpn.

.pro obtém IPsec (.scx) e as configurações SSL VPN autorizadas para o utilizador (.ovpn) através do VPN Portal, bem como alterações posteriores; não é um perfil de túnel. São suportados clientes Windows compatíveis e Sophos Connect para macOS a partir de 2.1, não o cliente macOS 2.0 ou anterior. O provisioning IPsec requer Sophos Connect 2.1 ou posterior. No cliente macOS 2.0 continuam a ser necessários importação direta e atualização manual controlada.

Se o gateway de provisioning ou vpn_portal_port mudar, o ficheiro .pro também deverá ser ajustado e redistribuído. O campo anterior user_portal_port é aceite apenas por compatibilidade. No primeiro provisioning com OTP ou outro método MFA, o início de sessão poderá aparecer duas vezes: primeiro para descarregar os perfis e depois para estabelecer o túnel.

Se o ficheiro .pro fornecer apenas uma conexão IPsec ou nenhuma configuração SSL VPN, verifique primeiro Policy members, associação ao grupo, disponibilidade de VPN Portal e autenticação.

Para o provisionamento SSO com .pro em Windows com Sophos Connect 2.4 ou posterior, o SFOS 22 descreve Entra ID; o SFOS 23 suporta os fornecedores de identidade OIDC compatíveis com este percurso, não qualquer fornecedor. Em Authentication > Services, VPN Portal, IPsec VPN e SSL VPN têm de utilizar o mesmo servidor IdP configurado. gateway contém apenas o FQDN ou endereço IP da firewall indicado na secção Redirect URI desse servidor, não o URI de callback completo; a porta do portal define-se separadamente em vpn_portal_port. Para SSO, macOS com Sophos Connect 2.1 ou posterior continua aqui limitado a Entra ID, sem extensão a OIDC em geral; a confirmação de suporte antes da implementação indicada abaixo continua a ser necessária. O artigo de provisionamento seguinte explica os pré-requisitos específicos do fornecedor e da versão.

Provisionamento do Sophos Connect com .pro e GPO descreve a estrutura JSON completa, os campos MFA, a seleção de gateways e a distribuição por GPO.

Para Google Workspace SSO, esta orientação limita-se a Windows com Sophos Connect 2.4 ou posterior; as indicações Entra para macOS não se aplicam ao Google. Para Entra, as páginas de visão geral indicam macOS a partir de 2.1, não 2.0, enquanto as páginas de requisitos indicam apenas Windows a partir de 2.4. Esta contradição também permanece por resolver no artigo detalhado ligado: pare antes de uma implementação macOS até confirmar e testar separadamente o suporte para o build de destino, plataforma/versão do cliente e tipo de VPN necessário. Para cada percurso aprovado, verifique definições SFOS compatíveis, configuração atual do cliente, métodos de autenticação e Redirect URI; teste MFA no IdP. Não se garante um fluxo de navegador idêntico nem a aplicabilidade da implementação GPO do Windows ao macOS.

Os nomes dos perfis devem ser exclusivos, entradas de conexão antigas devem ser removidas após a troca de gateway ou utilizador, e a distribuição deve ser verificada com um utilizador comum do grupo de destino. Para informações sobre versões do cliente, consulte Atualizar o Sophos Connect com segurança.

SSL VPN com Sophos Connect: Windows 10/11; cliente macOS 2.0 em macOS 13+ e cliente 2.1 ou posterior em macOS 14+. Linux, iOS e Android utilizam um cliente OpenVPN compatível.

Em Current activities > Remote users, os utilizadores remotos com sessão iniciada podem ser filtrados por Connection date, Username, Source IP address e Leased IP address. A coluna Mode distingue três estados:

SSL VPN (remote access): túnel de acesso remoto estabelecido
User portal (clientless access): início de sessão no portal por um membro de uma policy SSL VPN clientless
User portal: início de sessão no portal sem essa associação

Uma entrada do portal não comprova, portanto, a existência de um túnel SSL VPN. Disconnect termina a sessão selecionada. Antes de um teste de suporte ou aceitação, documentar o utilizador, os endereços, o modo e a hora.

Testar a configuração e isolar erros

Teste de aceitação

Um teste completo utiliza um utilizador piloto comum e um destino interno específico:

O utilizador vê exatamente a configuração SSL VPN esperada em VPN Portal.
Testar o MFA com um fator correto e outro incorreto.
Importar .ovpn ou .pro e verificar o endereço atribuído.
Com Split Tunnel, verificar a rota para LAN_Server e DNS_Internal.
Testar o destino interno primeiro pelo endereço IP e depois pelo nome do host.
Acessar o serviço permitido e verificar Firewall Rule ID em Log Viewer.
Gerar um acesso não permitido e confirmar o drop.
Com Full Tunnel, verificar também o acesso público à Internet, DNS, Web Policy e IPv4-SNAT.
Após alterar uma política ou um FQDN, desconectar, reconectar e repetir o mesmo teste.

Cada teste deve registrar hora, utilizador e grupo, plataforma e versão do cliente, rede de origem, destino e serviço. Se apenas um administrador for testado, erros de grupo, MFA e política poderão passar despercebidos.

Logs por fase do erro

Primeiro, é preciso determinar se o erro ocorre no acesso ao portal, na autenticação, no estabelecimento do túnel ou somente no acesso ao destino:

VPN Portal: vpnportal.log
Autenticação normal: access_server.log
Microsoft Entra SSO no SFOS 22: oauth_sso_vpn.log; para SFOS 23, use as indicações de logs específicas da versão no artigo detalhado Entra ou Google correspondente.
Certificados SSL VPN específicos do utilizador: peruser_cert_sslvpn.log
Serviço SSL VPN: sslvpn.log
Conexões ativas: openvpn-status*.log
Tráfego para o destino: log do firewall, Rule ID e, se necessário, Packet Capture

Em Packet Capture, Incoming apenas comprova que o firewall recebeu o pacote. Se aparecer Forwarded, mas não houver resposta, verifique a rota de retorno, o NAT, o sistema de destino e o firewall local desse sistema.

No tráfego TUN, os logs do SFOS podem apresentar o endereço da interface TUN como origem e o endereço atribuído ao cliente como destino. Isto não significa que os endereços estejam invertidos. Para interpretar a entrada, devem ser considerados em conjunto o utilizador, a lease, o sentido do tráfego, a Rule ID e a hora do teste.

O mapeamento de outros processos e ficheiros é explicado em Serviços e logs do Sophos Firewall.

Nenhum utilizador consegue estabelecer um túnel: serviço e limites de flood

Quando todos os utilizadores são afetados, efetue primeiro verificações só de leitura antes de alterar políticas, limites de flood ou serviços. Registe a hora do teste, o protocolo e a porta SSL VPN configurados, as definições DoS atuais e se existe pelo menos uma política SSL VPN.

Inicie sessão na CLI, selecione 5. Device management e, em seguida, 3. Advanced shell, e verifique o estado do serviço com o comando documentado pela Sophos:
```
service -S | grep sslvpn
```
O serviço deve apresentar Running. UNREGISTERED significa que não está registada nenhuma política SSL VPN; verifique se existe pelo menos uma. Se existir uma política, mas o serviço continuar sem apresentar Running, correlacione sslvpn.log com a hora do teste e investigue essa discrepância em vez de reiniciar serviços sem um procedimento documentado.
Em Intrusion prevention > DoS & spoof protection > DoS settings, inspecione as opções e os limites de flood ativados para UDP, TCP e ICMP/ICMPv6. Para o tráfego do túnel, utilize o protocolo SSL VPN configurado. O SFOS elimina o tráfego SSL VPN e os pedidos de ping quando o limite de flood correspondente é ultrapassado; um ping falhado, por si só, não prova que isso aconteceu. Correlacione a tentativa de ligação com evidências da eliminação antes de criar uma exceção.
Apenas quando se confirmar uma correspondência com o limite de flood, registe a configuração existente e crie em DoS bypass rules a regra temporária inbound mais restrita possível. O exemplo da Sophos utiliza o endereço IP/máscara de rede de origem relevante (ou * apenas se for inevitável), o endereço do recurso de rede permitido como destino, o protocolo real TCP ou UDP, a porta de origem Any e a porta de destino SSL VPN configurada (8443 por predefinição). Restrinja ainda mais a origem e o destino quando o teste o permitir; não desative globalmente a proteção contra floods.
Repita os mesmos testes cronometrados de ligação e acesso ao recurso permitido. Se a regra de bypass não explicar a eliminação, remova-a imediatamente. Após o diagnóstico, remova a regra temporária ou aprove e documente formalmente a exceção restrita. Restaure quaisquer limites de flood alterados separadamente para os valores registados e repita os testes de acesso permitido e bloqueado.

O pedido chega ao servidor, mas falta a resposta

Se estiver comprovado que o pedido do cliente SSL VPN chega ao recurso interno permitido, mas a resposta não regressa ao cliente, o percurso de retorno é verificado em duas etapas: primeiro do recurso para o firewall e depois do firewall para o endereço SSL VPN atribuído. Um estado verde do túnel não permite isolar este erro.

No recurso interno ou no respetivo router, verificar se o percurso de retorno para o intervalo de endereços SSL VPN passa pelo Sophos Firewall. Uma rota de retorno específica é mais transparente do que SNAT. Utilizar SNAT apenas de forma limitada quando não for possível encaminhar o retorno e a alteração resultante do endereço de origem for aceitável.
Confirmar com Packet Capture que a resposta chega ao firewall. O endereço de origem, o endereço de destino atribuído, o serviço e a hora do teste devem corresponder ao acesso original.
Em Routing > SD-WAN routes, verificar a Route Precedence atual e as rotas SD-WAN abrangentes. SSL VPN pertence à categoria static. Se sdwan_policyroute surgir antes, uma rota com o recurso interno ou Any como origem e Any como destino e serviço pode desviar a resposta do túnel.
Restringir preferencialmente a rota SD-WAN afetada para que o intervalo de endereços SSL VPN deixe de corresponder como destino. A Sophos menciona, em alternativa, uma exceção de serviço para a porta e o protocolo SSL VPN; esta variante deve corresponder ao desenho real das regras e do tráfego.
Alterar a Route Precedence global apenas depois de avaliar o impacto. A alteração afeta mais do que esta ligação. Preparar a ordem inicial, o acesso de gestão e o rollback conforme descrito em Route Precedence no Sophos Firewall.
Repetir o acesso e verificar na captura a entrada da resposta proveniente do recurso e o reencaminhamento para o endereço atribuído. Depois, voltar a estabelecer a ligação e repetir o teste com a mesma aplicação.

⚠️ Uma regra abrangente com Any, uma regra SNAT geral ou uma alteração global da Route Precedence podem deslocar o problema visível e afetar outros percursos de VPN, WAN ou gestão. Parar se o percurso de retorno para o firewall ou a rota SD-WAN que realmente corresponde não estiverem comprovados.

A rede doméstica e a rede interna de destino sobrepõem-se

Se, por exemplo, o cliente externo utilizar 192.168.1.0/24 e o recurso interno permitido também estiver em 192.168.1.0/24, o sistema operativo considera normalmente o destino como local. O pacote não chega sequer ao túnel SSL VPN. A solução permanente mais limpa consiste em renumerar uma das duas redes.

Se isso não for possível de imediato, a Sophos documenta uma alternativa DNAT estritamente limitada. Escolhe-se um endereço virtual de destino livre que não se sobreponha a nenhuma rede local, interna, VPN, estática ou SD-WAN. Com Split Tunnel, este endereço tem de chegar ao cliente como Permitted network resource, seguido de uma nova ligação. A regra DNAT utiliza o intervalo de leases SSL VPN como Original source, Original como Translated source, o endereço virtual como Original destination e o host interno real como Translated destination. Os serviços e a regra de firewall associada de VPN para a zona de destino ficam limitados ao acesso realmente necessário.

O utilizador acede depois ao endereço virtual ou a um nome DNS dedicado que resolva para esse endereço. O Log Viewer deve mostrar a Firewall Rule ID e a NAT Rule ID esperadas; um Packet Capture confirma a tradução e o caminho de retorno. Não criar um intervalo de substituição completo se apenas for necessário um host. Parar se não for possível confirmar inequivocamente que o endereço virtual está livre ou se for necessária uma regra NAT ampla.

Problemas comuns

Ficheiro .ovpn ausente ou vazio no VPN Portal: Resolver um download OVPN ausente ou vazio distingue erros de policy, User ID, certificado, armazenamento, firmware e HA. As contas Guest não são permitidas. O Sophos Connect só suporta nomes de utilizador ASCII; o nome do utilizador e o domínio podem ter, em conjunto, no máximo 51 carateres.
O login falha: comparar access_server.log e vpnportal.log com a hora do teste; para Entra no SFOS 22, usar também oauth_sso_vpn.log, e no SFOS 23 as indicações de logs OIDC específicas da versão no artigo detalhado correspondente. Verificar o mesmo servidor IdP para o portal e SSL VPN, as Redirect URIs e a cadeia de certificados completa.
O túnel está estabelecido, mas faltam destinos internos: verificar a rota no endpoint, Permitted Resources com Split Tunnel, a regra de firewall, a rota de retorno, o firewall de destino e qualquer sobreposição com a rede doméstica local.
O endereço IP funciona, mas o nome do host não: verificar servidores DNS, domínio de pesquisa, rota Split Tunnel, regra de firewall para DNS, DoH local ou DNS do endpoint e, se necessário, Device Access para DNS.
Somente alguns utilizadores são afetados: comparar associação ao grupo, atribuição de política, MFA, IP estático, Simultaneous logins e perfil carregado.
Somente clientes antigos são afetados: importar um ficheiro .ovpn atualizado após mudanças globais. Se apenas a política ou um FQDN tiver mudado, reconectar primeiro e verificar o roteamento carregado.
Full Tunnel sem Internet: verificar a regra de VPN para WAN, IPv4-SNAT, DNS e as Web/Security Policies aplicadas.
Grandes transferências travam: se acessos pequenos funcionarem, verificar MTU e MSS ao longo do caminho real. Consulte MTU e MSS para problemas de VPN para seguir o procedimento.
A conexão termina após um período mais longo: comparar a hora de início e de desconexão com Idle Timeout, Disconnect idle clients e Key Lifetime. Verificar IP estático e Simultaneous logins; se necessário, atribuir um endereço dinâmico a um utilizador piloto e analisar sslvpn.log e openvpn-status*.log à hora do teste.
Nenhum utilizador consegue estabelecer o túnel: além de Device Access e da liberação da porta, procurar uma regra DNAT ampla com Original destination: Any e Services: Any, ou com a porta SSL VPN, que intercepte previamente o estabelecimento da conexão.
WAF, o portal ou SSL VPN entram em conflito: comparar IP WAN, porta e protocolo de todos os serviços locais e das regras WAF. Combinações compartilhadas podem causar exposição adicional do portal ou impedir o funcionamento de Login Security.

Durante a operação, é necessário revisar periodicamente grupos, MFA, atribuições de IP estático, validade dos certificados, intervalo de endereços, Device Access, regras de firewall, distribuição de perfis e logs. Novas versões do SFOS e do Sophos Connect devem ser testadas primeiro com um utilizador piloto e com testes positivos e negativos de acesso aos destinos.