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.

Limitação da API XML para SFOS 22/23: A documentação da API legada relativa a Configure SSLVPN Tunnel Access indica para DisconnectDeadPeerAfter o valor predefinido de 300 segundos, o intervalo de 60 a 1800 e o valor 180 no exemplo, sem os associar a protocolos específicos. Isto não comprova um valor predefinido em execução para TCP/UDP nem um novo valor predefinido na GUI. Por isso, não substitua os valores TCP/UDP descritos acima com base nesta tabela da API; verifique o temporizador efetivamente guardado em Remote access VPN > SSL VPN > SSL VPN global settings no build instalado.

Também permanece por esclarecer a obrigatoriedade condicional no esquema de leases: LeaseMode permite IPv4, embora IPv6Lease e IPv6Prefix estejam indicados como campos obrigatórios e permaneçam vazios no exemplo; para o prefixo, a tabela indica 64 a 112. Isto não permite concluir que seja permitido enviar campos IPv6 vazios nem que falte suporte dual-stack. EndIP e CompressSSLVPNTraffic aparecem apenas no exemplo e não constituem um contrato de escrita validado nem uma recomendação de compressão. Antes de qualquer automatização que dependa destes dados, o Sophos Support ou a documentação aprovada para o build de destino têm de esclarecer os campos condicionalmente obrigatórios e os valores de escrita; até lá, não execute nenhuma alteração XML daí derivada. Para alterações suportadas, conserve previamente os valores globais efetivos dos temporizadores, leases e DNS, bem como as configurações dos pares SSL Site-to-Site afetados; depois, verifique a resposta, os valores guardados e a lease de um utilizador piloto que tenha voltado a ligar-se. Se a aceitação falhar, restaure exatamente os valores iniciais registados e as configurações dos pares correspondentes, e repita os mesmos testes de acesso.

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.

Limitação da API XML na política: Os exemplos Add/Edit para SFOS 22/23 separam, dentro de SSLVPNPolicy, os ramos TunnelPolicy e ClientlessPolicy, cada um com o seu próprio Name e PolicyMembers/Member. O acesso por túnel a recursos de rede e a publicação sem cliente são tarefas distintas, com nomes de políticas e atribuições de membros separados. WebAccessibleResources contém BookmarkGroups e Bookmarks, não recursos IP do túnel. Não trate uma alteração como uma alteração conjunta das duas subpolíticas; não reinterprete permissões de bookmarks como recursos do túnel.

A tabela indica ainda o campo obrigatório Web Access com os valores 1 e 6, sem um campo correspondente no exemplo nem uma correspondência confirmada com os modos da GUI. Para UseAsDefaultGateway, apresenta SplitTunnel como valor predefinido e, para DisconnectIdleClients, UseGlobalSettings, embora ambos indiquem apenas Off e On como valores permitidos. Não deduza daí uma correspondência numérica entre modos, um valor predefinido que possa ser enviado, o efeito de campos omitidos ou a serialização de membros. Mantenha pendente a alteração da API que dependa destes dados até ao esclarecimento para o build de destino; a configuração pela GUI descrita acima continua a ser o caminho seguro. Full Tunnel continua a exigir regras de firewall restritivas, e o valor de inatividade da política só pode reduzir 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.

Retirar uma política SSL VPN de serviço em segurança

Uma política que já não é necessária deve ser removida de forma seletiva; desligar uma sessão não substitui essa operação. Antes da eliminação, determine que acesso deve cessar e que permissões continuam a ser necessárias.

Selecione o Name exato guardado e o ramo de política pretendido: TunnelPolicy para acesso por túnel ou ClientlessPolicy para acesso sem cliente. Não se baseie apenas num nome apresentado semelhante.
Verifique Policy members, a pertença efetiva aos grupos e os recursos de rede atribuídos ou os bookmarks e grupos de bookmarks. Confirme que a retirada está aprovada e que nenhum acesso ainda necessário depende desta política. Se as atribuições não forem claras, pare e esclareça primeiro as dependências; uma nova atribuição pode remover membros de uma política anterior.
Conserve de forma protegida e recuperável o nome, o ramo, os membros e todas as definições associadas. Em Remote access VPN > SSL VPN, remova apenas a política selecionada através do procedimento de eliminação suportado pelo build de destino instalado. Se esse procedimento não estiver claramente confirmado, consulte a documentação aprovada ou o Sophos Support antes da alteração.
Se o acesso tiver de cessar imediatamente, verifique separadamente as sessões ativas em Current activities > Remote users, com base no utilizador, nos endereços e em Mode, e termine seletivamente as sessões afetadas com Disconnect. Desligar não substitui a revogação de permissões; não deduza da eliminação o encerramento automático dos túneis.
Volte a verificar as políticas guardadas e as atribuições de membros. Com um utilizador normal afetado, confirme a configuração esperada no VPN Portal e a autorização numa nova tentativa de ligação. O acesso anteriormente concedido pela política retirada deve cessar; o acesso ainda aprovado através de outras políticas deve manter-se. Verifique o tráfego efetivamente permitido e bloqueado com os logs da firewall e, no acesso sem cliente, também as permissões esperadas dos bookmarks. Esclareça resultados inesperados antes de outras eliminações; utilize as definições conservadas para uma reversão seletiva apenas após aprovação.

Limite documental: As páginas Delete da API XML legada para SFOS 22/23 indicam Name como parâmetro obrigatório, mas não confirmam um contrato XML completo de eliminação, efeitos em cascata nem a semântica dos resultados ou das sessões. Não deduza delas um payload Delete, códigos de estado, textos de mensagens ou a revogação imediata do acesso.

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 fallback, 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.

Completar a configuração e preparar o diagnóstico

Num ambiente novo, utilize Hosts and services > IP host > Add para introduzir um nome e uma rede ou endereço de host e selecione Save. Crie SSLVPN_Users em Authentication > Groups > Add com valores adequados de Surfing quota e Access time e guarde. Em Authentication > Users > Add, defina o nome de utilizador, o nome apresentado e este grupo e guarde. Acesso ilimitado à internet e horários sem restrições são valores de exemplo, não requisitos de segurança. Para utilizadores existentes do diretório, verifique a associação ao grupo em vez de criar contas locais desnecessárias.

Além dos valores globais descritos acima, verifique:

Lease mode: IPv4 only atribui apenas IPv4; IPv4 and IPv6 both atribui ambas as famílias de endereços. O pool IPv6, as rotas e as regras devem ser coerentes. Use static IP addresses apresenta o intervalo estático dividido automaticamente; atribua os endereços individuais em Authentication > Users.
IPv4 WINS: Introduza os servidores WINS primário e secundário apenas se o ambiente necessitar deste serviço de nomes. WINS não substitui DNS.
Encryption algorithm, Authentication algorithm e Key size: Escolha deliberadamente a encriptação, a autenticação de mensagens e o comprimento da chave de acordo com os requisitos de segurança aprovados. Key lifetime é indicado em segundos. Não enfraqueça a criptografia para diagnosticar uma ligação.
Enable debug mode: Fornece logs SSL VPN mais detalhados. Ative-o apenas para uma investigação específica, proteja os logs e reponha depois o estado anterior.

Guarde as alterações globais com Apply. Para uma cadeia de certificados assinada externamente, importe o certificado de servidor com a chave privada, a CA intermédia e a CA raiz. Alterações a Default CA ao utilizar ApplianceCertificate ou um certificado assinado localmente também exigem uma nova importação manual de .ovpn. Não utilize caracteres UTF-8 nos campos de certificado e CA; caracteres especiais nos nomes de utilizador também podem afetar o portal, nomes de ficheiros e clientes de terceiros.

Com um único IP WAN público estático, Override hostname pode ficar vazio. Com vários endereços, defina o FQDN pretendido ou um endereço de interface específico, ou verifique cada entrada exportada. Atrás de NAT a montante, indique o ponto de acesso público do router e verifique o encaminhamento de portas; para um endereço dinâmico, configure primeiro Network > DDNS e utilize o FQDN DDNS. Inspecione as entradas reais de gateway em .ovpn e teste a resolução de nomes separadamente.

No assistente, verifique os valores globais, selecione Next e defina VPN name, utilizadores/grupos e Authentication servers. As opções são Same as VPN (IPsec, L2TP, PPTP), Same as firewall ou Set authentication method for SSL VPN. Selecione o modo de túnel e as zonas separadamente; para Split Tunnel, confirme os recursos com Apply selected items no fim da lista. Selecione Finish apenas após verificar as definições e confira as regras geradas. O assistente não substitui a verificação de SNAT nem a configuração separada do IdP.

⚠️ A introdução do guia Full Tunnel afirma que apenas os recursos selecionados na política são acessíveis; a ajuda do campo indica expressamente que Permitted network resources não é aplicado com Use as default gateway. Um guia de diagnóstico anterior também continua a recomendar a seleção de recursos neste modo. Esta afirmação contraditória não garante o controlo de acesso: utilize regras de firewall explícitas como controlo para Full Tunnel e teste destinos permitidos e bloqueados. As regras de exemplo amplas com Any não são obrigatórias; restrinja separadamente o acesso interno e à internet.

Para configurar o cliente manualmente, abra VPN em VPN Portal, selecione Download for Windows ou Download for macOS se necessário e instale o cliente. Download configuration for Windows, macOS, Linux fornece .ovpn; importe-o com Import connection e inicie sessão com as credenciais do portal ou o SSO preparado. O administrador também pode obter o instalador através de Remote access VPN > SSL VPN > Download client. O antigo cliente SSL VPN chegou ao fim de vida e já não é disponibilizado no portal.

Se apenas alguns endpoints falharem, verifique primeiro o acesso à internet e as permissões do sistema operativo, firewall do endpoint e antivírus. Durante uma tentativa de ligação, utilize o filtro BPF port <SSL VPN port number> em Diagnostics > Packet capture; Details no Sophos Connect apresenta os parâmetros da ligação. A ausência de pacotes não prova um bloqueio do ISP. Exclua primeiro outras causas; mude para uma combinação permitida de porta/protocolo apenas após verificar conflitos WAF/portal e preparar a distribuição de perfis e o rollback. O problema documentado de compressão Android/OpenVPN afeta SFOS 20.0 GA e versões anteriores, não SFOS 22/23 de forma geral.

Com o túnel estabelecido, verifique na tabela de routing do endpoint a rede de destino, a interface TUN e o endereço atribuído. Se faltar a rota, volte primeiro a ligar e verifique o log do cliente e as permissões do endpoint; reimportar só ajuda com a configuração atual adequada. Em Log viewer > Firewall, filtre por In interface, Is, tun e verifique o ID de Firewall rule. Para regras específicas de utilizador, confira também Match known users e User or groups. Para distinguir problemas VPN de problemas de rede interna, teste a conectividade do firewall ao destino em Diagnostics > Tools; retire depois qualquer permissão temporária de ping. Em caso de reconexões, verifique também alterações de atribuição de endereços, DNS/WINS e domínio, e não utilize interfaces WAN como Permitted network resources. Alterações de política não terminam automaticamente os túneis existentes: os utilizadores devem desligar e voltar a ligar separadamente.

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. Se o serviço apresentar UNREGISTERED, verifique se existe pelo menos uma política SSL VPN. 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. Para esta exceção de diagnóstico, utilize 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 de ligação e acesso ao recurso permitido, registando a hora de execução. 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.