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 usuários 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 arquivo 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 usuários 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 usuários 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;
usuários 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 usuários 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 usuários 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.

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:

SSL server certificate, nos ajustes globais de SSL VPN, autentica o servidor do túnel.
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 compartilhar 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 habilitadas 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.

Para IPv4, o SFOS aceita aqui, no máximo, uma rede /24; redes menores, como /25, não podem ser selecionadas. O acesso não é limitado por um pool artificialmente pequeno, mas pela política e pelas 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, o serviço DNS será permitido 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 usuário 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 usuário local, limita os logins simultâneos. O valor global se aplica apenas aos usuários 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.

Criar a política SSL VPN

A política é criada manualmente ou pelo assistente:

Remote access VPN > SSL VPN

O assistente mostra os ajustes globais apenas para revisão e não permite alterá-los. Ele cria a política, define a autenticação selecionada e o Device Access para VPN Portal e SSL VPN e gera a regra de firewall. 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.
Configurar opcionalmente Disconnect idle clients e Override global timeout.
Salvar e verificar a configuração com um membro comum do grupo de destino.

Usuários e grupos convidados não podem ser usados como Policy members. Se um usuário ou grupo já estiver incluído em uma política SSL VPN anterior, o SFOS removerá essa atribuição da política anterior. Portanto, as sobreposições devem ser verificadas antes de salvar.

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 usuários afetados precisam desconectar e reconectar.

Com Full Tunnel, Use as default gateway é ativado. Todo o tráfego do usuário 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 usuários 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.

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.

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 login no portal e o download do perfil, enquanto SSL VPN authentication methods controla o login no túnel. WebAdmin é uma interface administrativa separada e não precisa ser habilitada na zona WAN para usar SSL VPN.

Com Microsoft Entra ID, o mesmo servidor Entra deve ser selecionado para VPN Portal e SSL VPN. A configuração completa é descrita em Microsoft Entra ID SSO para Sophos Connect.

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 usuário piloto comum. Consulte MFA para Sophos Firewall para obter mais informações.

Distribuir e atualizar o perfil do cliente

Quando um arquivo .ovpn é importado manualmente, as alterações globais relevantes para o perfil devem ser baixadas e importadas novamente. Isso inclui especialmente protocolo, porta, interface, certificado do servidor e outros valores da configuração global de SSL VPN. Uma atualização do Sophos Connect não substitui um perfil desatualizado.

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. Essas alterações não exigem um novo download do arquivo .ovpn.

Um arquivo de provisioning .pro é compatível apenas com Windows 10 e 11. Ele baixa automaticamente as configurações IPsec e SSL VPN disponíveis para o usuário e alterações posteriores. Se o gateway de provisioning ou a porta de VPN Portal mudar, o arquivo .pro também deverá ser ajustado e redistribuído. No primeiro provisioning, o login poderá aparecer duas vezes: primeiro para baixar os perfis e depois para estabelecer o túnel.

Se o arquivo .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.

Após ativar ou alterar Microsoft Entra ID SSO, o cliente deve usar uma configuração atualizada. Entra SSO no Sophos Connect é um cenário do Windows a partir da versão 2.4 do cliente.

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

Testar a configuração e isolar erros

Teste de aceitação

Um teste completo utiliza um usuário piloto comum e um destino interno específico:

O usuário 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 horário, usuário 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: oauth_sso_vpn.log
Certificados SSL VPN específicos do usuário: 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.

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

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, vpnportal.log ou oauth_sso_vpn.log com o horário do teste. Com Entra, verificar o mesmo servidor para o portal e SSL VPN, além da 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 usuários 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 arquivo .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 o horário 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 usuário piloto e analisar sslvpn.log e openvpn-status*.log no horário do teste.
Nenhum usuário 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 usuário piloto e com testes positivos e negativos de acesso aos destinos.