Configurar SSL VPN Site-to-Site na Sophos Firewall

Uma SSL VPN Site-to-Site liga as redes internas de duas Sophos Firewalls através de um túnel cifrado. Ao contrário do IPsec, cada lado tem um papel fixo: a firewall cliente estabelece sempre a ligação e a firewall servidor aceita-a.

Esta solução é especialmente adequada quando uma filial tem um endereço IP público dinâmico ou quando o IPsec encontra dificuldades numa rede a montante. A sede com endereço estático ou FQDN estável torna-se o servidor e a filial torna-se o cliente. Para redes em crescimento, routing dinâmico, redundância ou uma contraparte de outro fabricante, o IPsec route-based é geralmente mais flexível; numa pequena ligação entre duas firewalls Sophos, a SSL Site-to-Site pode ser mais simples.

Este guia utiliza um exemplo concreto:

Sede, servidor: vpn.example.com, rede local 10.10.0.0/24
Filial, cliente: endereço IP público dinâmico, rede local 10.20.0.0/24
Ligação: HQ-to-Branch
Porta SSL VPN: 8443

vpn.example.com, os nomes dos objetos e as duas redes são placeholders que devem ser substituídos pelos valores do próprio ambiente. 8443 é a porta predefinida; só permanece inalterada se a utilização de portas e o design de segurança forem compatíveis.

O procedimento resumido é: definir papéis e redes, verificar os valores globais de SSL VPN, permitir SSL VPN na zona WAN do servidor, criar a ligação de servidor, exportar o ficheiro .apc, importá-lo na firewall cliente e, em seguida, verificar rotas, regras e tráfego real de utilização.

⚠️ Os ajustes globais de SSL VPN também são utilizados pelo Remote Access SSL VPN. Por isso, não se deve alterar a porta, o protocolo, o certificado, o intervalo de endereços ou a criptografia apenas para este túnel. Primeiro, é necessário verificar o impacto nas ligações e nos perfis de utilizadores existentes.

Planear papéis, redes e acesso público

A firewall servidor deve, de preferência, ser o appliance mais estável e, no caso de modelos diferentes, o mais potente. Se apenas um dos lados tiver um endereço IP público estático, é preferível que esse lado assuma o papel de servidor. O cliente pode estar atrás de NAT ou numa ligação com endereço dinâmico, desde que consiga alcançar o servidor.

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

IP público ou FQDN da firewall servidor;
protocolo e porta para SSL VPN;
rede local da sede e rede local da filial;
intervalos de endereços exclusivos e não sobrepostos;
serviços necessários e direções de ligação permitidas;
caminho de retorno em ambos os lados;
acesso administrativo alternativo para a alteração;
versões atuais do SFOS em ambas as firewalls.

Se as redes se sobrepuserem, esta configuração padrão não é suficiente. É necessário um design deliberado de tradução e routing; na prática, o IPsec com NAT planeado costuma ser mais adequado.

Verificar a compatibilidade antes da alteração

Desde o SFOS 20.0 MR1, a Sophos utiliza um componente OpenVPN mais recente. Os túneis SSL Site-to-Site do SFOS 20.0 MR1 ou posterior não se ligam ao SFOS 18.5 ou anterior, nem ao UTM 9. Numa combinação deste tipo, é necessário atualizar ambas as Sophos Firewalls ou utilizar IPsec ou um túnel RED.

Verificar os ajustes globais de SSL VPN

Os ajustes comuns encontram-se na futura firewall servidor em:

Remote access VPN > SSL VPN > SSL VPN global settings

No exemplo, são verificados sobretudo estes valores:

Protocol: UDP é geralmente a escolha inicial mais eficiente; TCP pode ajudar em redes restritivas.
SSL server certificate: deve ser válido e estar importado com a chave privada e a cadeia de certificados completa. Com um FQDN público, é preferível que o certificado corresponda a esse nome.
Override hostname: vpn.example.com, se os clientes tiverem de utilizar exatamente este FQDN.
Port: 8443, desde que não exista outro design de portas planeado deliberadamente.
Assign IPv4 addresses: não pode colidir com as duas redes dos locais nem com outros pools de VPN.
Cryptographic settings: não alterar os valores existentes sem testes de compatibilidade e funcionamento.

Se a firewall servidor estiver atrás de um router a montante, este deve encaminhar a porta e o protocolo escolhidos para a firewall. Nesse caso, o FQDN aponta para o endereço público do router. WAF e SSL VPN não podem utilizar a mesma combinação de IP WAN, porta e protocolo.

Se Port, Protocol, SSL server certificate ou Override hostname forem alterados posteriormente, a configuração do servidor deve ser novamente descarregada e importada na firewall cliente. A exportação .apc existente não conhece os novos valores.

As dependências completas dos ajustes globais são explicadas em Remote Access SSL VPN na Sophos Firewall. As alterações são planeadas considerando perfis de utilizador existentes, intervalos de lease, DNS e serviços acessíveis publicamente.

Permitir SSL VPN para a zona WAN do servidor

Na firewall servidor, o serviço SSL VPN local é permitido para a zona de entrada:

Administration > Device access

Se a firewall cliente tiver um endereço público dinâmico ou que não possa ser restringido de forma útil, ativa-se SSL VPN para WAN em VPN services. Isto permite apenas o estabelecimento do túnel para a firewall; não substitui uma regra de firewall para o tráfego de utilização entre os locais.

Se as redes de origem públicas do lado do cliente forem conhecidas e estáveis, SSL VPN permanece desativado na matriz WAN. Em vez disso, cria-se uma exceção Accept Local Service ACL Exception específica com Source zone WAN, os Source Networks/Hosts conhecidos, o endereço WAN do servidor como Destination host e o serviço SSL VPN. Uma exceção Accept não restringe uma permissão já ativa na matriz WAN. O planeamento é explicado em Configurar Device Access com segurança na Sophos Firewall.

Criar a ligação de servidor na sede

Primeiro, as duas redes são criadas como objetos de host IP na firewall servidor:

Hosts and services > IP host

HQ-LAN: 10.10.0.0/24
Branch-LAN: 10.20.0.0/24

Em seguida, cria-se a ligação de servidor:

Abrir Site-to-site VPN > SSL VPN.
Na área Server, clicar em Add.
Introduzir HQ-to-Branch como nome.
Em Local networks, selecionar HQ-LAN.
Em Remote networks, selecionar Branch-LAN.
Ativar Use static virtual IP address apenas quando existir uma necessidade justificada e escolher um endereço livre fora dos intervalos SSL VPN estáticos e dinâmicos globais.
Guardar com Save.

Do ponto de vista da firewall servidor, Local networks são as redes da sede. Remote networks encontram-se atrás da firewall cliente. Esta perspetiva é importante: se os objetos forem trocados, o túnel pode ficar verde enquanto as rotas e regras não correspondem à ligação pretendida.

Exportar a configuração do servidor em segurança

Na lista de servidores, selecionar Download em HQ-to-Branch. A exportação tem a extensão .apc e contém os dados de ligação para a firewall cliente.

Para uma transferência segura, ativa-se Encrypt configuration file e define-se uma palavra-passe temporária forte. O ficheiro e a palavra-passe são transmitidos por canais separados. O ficheiro .apc não deve ser colocado num ticket público, num chat desprotegido ou num diretório de downloads permanente.

Importar a configuração na firewall cliente

Na firewall da filial, a importação é efetuada no mesmo caminho de menu:

Abrir Site-to-site VPN > SSL VPN.
Na área Client, clicar em Add.
Introduzir Branch-to-HQ como nome.
Em Configuration file, selecionar o ficheiro .apc exportado.
Se a exportação estiver cifrada, introduzir a palavra-passe.
Ativar Use HTTP proxy server apenas se a filial alcançar efetivamente o servidor através de um proxy HTTP explícito.
Definir Override peer hostname apenas se o endereço do servidor contido na exportação não for encaminhável ou resolvível a partir da rede cliente. No exemplo, o campo permanece vazio porque vpn.example.com já é exportado globalmente.
Guardar com Save e ativar a ligação.

O estado fica verde assim que a firewall cliente alcança o servidor e o túnel é estabelecido. Um estado verde confirma apenas a própria ligação, não o acesso a servidores, DNS ou aplicações.

Verificar rotas e regras de firewall

As redes selecionadas em Local networks e Remote networks tornam-se ativas para o routing do túnel. Pertencem à classe de routing static e têm de ser compatíveis com o resto da configuração de routing. Uma rota estática, SD-WAN ou VPN mais específica pode, caso contrário, produzir um caminho diferente do esperado. A ordem é explicada em Compreender e ajustar a prioridade de routing na Sophos Firewall.

As regras de firewall para o tráfego de utilização são criadas deliberadamente em ambas as firewalls ou comparadas com as regras existentes. No exemplo, em que a filial inicia ligações para a sede, é necessário pelo menos:

na firewall da filial, uma regra restrita de LAN para VPN para Branch-LAN até aos destinos necessários em HQ-LAN;
na firewall servidor, uma regra correspondente de VPN para LAN para Branch-LAN até esses destinos;
apenas os serviços necessários, por exemplo DNS, RDP e HTTPS;
Log firewall traffic para o teste de aceitação;
nenhuma regra SNAT ou MASQ que altere o tráfego entre locais sem motivo técnico.

Se a sede também tiver de iniciar novas ligações para a filial, as direções inversas são permitidas separadamente. Uma regra Any ampla não é um design de segurança concluído. Testar uma regra de firewall mostra como verificar em conjunto a posição da regra, a Rule ID e o Packet Capture.

Validar o túnel e o tráfego de utilização

O teste começa com um cliente específico e um destino específico. No exemplo, um dispositivo de 10.20.0.0/24 acede a um servidor permitido em 10.10.0.0/24.

Verificar o estado verde e o aumento dos contadores de bytes em ambas as firewalls.
Testar primeiro o destino pelo endereço IP e depois pelo hostname.
Aceder a um serviço realmente permitido, como HTTPS ou RDP.
No Log Viewer, verificar a Firewall Rule ID esperada e os endereços de origem e destino inalterados.
Testar um serviço não permitido ou um destino não autorizado e confirmar o bloqueio.
Verificar separadamente a direção inversa, caso deva ser permitida por motivos operacionais.
Após um reinício ou mudança de WAN, verificar se a firewall cliente volta a estabelecer o túnel.

Um ping bem-sucedido não é suficiente. Não comprova o DNS nem o serviço de aplicação necessário. Num sistema de destino interno, a regra de firewall, o caminho de retorno e a firewall do endpoint têm de corresponder ao teste; Device Access só é relevante se for feito ping a um endereço da própria Sophos Firewall.

Ler os logs em caso de erro

Em Site-to-site VPN > SSL VPN > Logs, é possível abrir diretamente os logs de SSL VPN. Para uma verificação mais aprofundada, inicia-se sessão por SSH, seleciona-se 5. Device Management > 3. Advanced Shell e lê-se o log atual do serviço:

tail -n 200 /log/sslvpn.log

O comando não altera a configuração. A hora, o nome da ligação e o lado servidor/cliente são documentados em conjunto. Dependendo do número de processos, podem existir outros ficheiros de estado OpenVPN como openvpn-status0.log, openvpn-status1.log e ficheiros adicionais; a correspondência é explicada em Logs de serviço da Sophos Firewall.

Delimitar erros típicos de forma específica

O túnel permanece vermelho: verificar o FQDN público, DNS, port forwarding, protocolo, certificado e SSL VPN em Device Access para a zona WAN do servidor. Depois, ler sslvpn.log para o mesmo momento.
Após uma alteração global, o túnel deixa de ser estabelecido: exportar novamente a configuração do servidor e voltar a importá-la no cliente. A porta, o protocolo, o certificado e Override hostname dependem especialmente da exportação.
O túnel está verde, mas não há tráfego: verificar o routing do túnel, a prioridade de routing, as regras em ambas as firewalls, a Rule ID, o caminho de retorno, NAT e a firewall do endpoint. Depois, seguir um único fluxo com Packet Capture.
Apenas os nomes não funcionam: testar o acesso por IP, verificar o servidor DNS e o domínio de pesquisa e garantir que o servidor DNS está acessível e permitido através do túnel.
O objeto de host FQDN ainda aponta para o endereço antigo: os hosts e grupos FQDN são suportados como redes locais e remotas. Após uma alteração de DNS, desligar e voltar a ligar o túnel de forma controlada e depois verificar a rota e o tráfego de utilização para o IP recém-resolvido. Uma falha de resolução é primeiro um erro de tráfego ou routing, não automaticamente um erro no estabelecimento do túnel.
O cliente só alcança o servidor através de um proxy: utilizar Use HTTP proxy server com os valores de proxy aprovados; não introduzir dados de proxy aleatórios como workaround geral.
Um dos lados utiliza SFOS 18.5 ou UTM 9: não continuar a procurar a causa na porta ou no certificado. Esta combinação é incompatível com uma contraparte atual; atualizar ambos os lados ou utilizar IPsec ou RED.

Se o túnel continuar pouco claro após um teste controlado, devem ser guardados a versão e o build do SFOS de ambas as firewalls, a hora com fuso horário, o nome da ligação, sslvpn.log, Rule IDs e um Packet Capture curto. Só depois se devem continuar a alterar regras, redes ou valores globais de SSL VPN.