Utilizar em segurança as definições VPN globais do Sophos Firewall

A Device Console do Sophos Firewall contém em set vpn definições globais para failover VPN, processamento IPsec e os protocolos legacy L2TP e PPTP. Não afetam apenas a ligação que está a ser analisada. Um teste pouco direcionado pode influenciar outros túneis, remover sessões existentes ou enfraquecer uma função de proteção.

Não é uma receita geral de desempenho: ipsec-max-workqueue-items, a janela anti-replay e use-resolved-ip-address não devem ser colocados preventivamente em valores superiores ou em enable. A Sophos descreve-os como definições avançadas para uma necessidade concreta de rede ou por indicação do Sophos Support.

Para problemas normais de túnel, começar pelo troubleshooting de VPN IPsec. Aí são verificados IKE, Child SA, routing, NAT, regras e o fluxo real de pacotes. Os switches globais deste artigo só são relevantes quando o sintoma corresponde exatamente à sua finalidade.

Registar o estado inicial antes de cada alteração

Os comandos são executados em 4. Device Console. Antes de definir um valor, documentar a versão e build do SFOS, hora, túneis afetados, fluxo de teste esperado e um acesso de gestão independente. Consultar separadamente os valores existentes:

show vpn conn-remove-on-failover
show vpn conn-remove-tunnel-up
show vpn ipsec-performance
show vpn configuration

show vpn ipsec-performance mostra, entre outros, os valores de workqueue e replay. show vpn configuration é relevante para a configuração atual de L2TP e PPTP. Se um valor não aparecer no output da build instalada, não deve ser deduzido de um default presumido. Antes de alterar uma definição avançada global, o change deve incluir um backup da configuração e o Sophos Support.

O rollback utiliza sempre o valor efetivamente lido no appliance. default não está documentado como rollback universal para estes comandos VPN e não deve ser usado por suposição.

Sessões durante transições de túnel e WAN

conn-remove-tunnel-up determina se as ligações existentes são removidas quando um túnel IPsec fica ativo. Isto pode ser importante quando um fluxo começou noutro caminho e permanece preso a esse caminho depois de o túnel subir. A remoção também pode interromper sessões produtivas. As configurações novas usam disable por predefinição desde o SFOS 19.0, enquanto os sistemas migrados podem conservar um valor anterior.

set vpn conn-remove-tunnel-up enable
set vpn conn-remove-tunnel-up disable

conn-remove-on-failover controla a limpeza global durante failover e failback. all afeta todas as ligações, enquanto non-tcp limita a limpeza ao tráfego não TCP, como UDP ou ICMP. O valor correto não é apenas uma decisão VPN: VoIP, videoconferência, DNS e outras aplicações UDP devem ser observados na mesma janela de teste.

set vpn conn-remove-on-failover all
set vpn conn-remove-on-failover non-tcp

A Sophos alterou estes defaults no SFOS 19.0 para novas configurações, reduzindo o flapping de ligações não TCP quando os túneis IPsec sobem ou descem. A alteração não foi aplicada globalmente em upgrades e migrações. No SFOS 22, importa por isso o output atual do dispositivo, não um valor de fábrica presumido.

Em HA, é também necessário considerar que o Sophos Firewall não transfere sessões VPN e não TCP para o peer como sessões TCP encaminhadas normais. Os dois switches conn-remove-* não substituem nem o design HA nem um teste de failover controlado.

Desempenho IPsec e funções de proteção

O grupo ipsec-performance contém quatro funções muito diferentes. O nome pode incentivar experiências de tuning, embora apenas uma função defina diretamente o tamanho de uma fila de trabalho.

Alterar a workqueue apenas perante um bottleneck comprovado

ipsec-max-workqueue-items aceita valores de 1024 a 10240. A fila contém trabalho para o processamento IPsec. Um valor maior não garante mais throughput e não corrige Packet Loss, problemas de MTU, resultados fracos com um único stream ou uma ligação WAN saturada.

set vpn ipsec-performance ipsec-max-workqueue-items <1024-10240>

Uma alteração só faz sentido quando um teste de carga reproduzível, a utilização do sistema e o diagnóstico Sophos indicam exatamente este bottleneck. Primeiro são verificados separadamente MTU e MSS, latência, Packet Loss, perfil de encriptação, IPsec Acceleration e streams paralelos. Sem melhoria, repõe-se o valor inicial registado.

A janela anti-replay é uma função de segurança

Dentro da janela replay, o IPsec regista os pacotes já vistos durante a desencriptação. Pode assim detetar e descartar pacotes repetidos. O SFOS 22 aceita 0, 32, 64, 128, 256, 512, 1024, 2048 e 4096; o default documentado é 1024.

set vpn ipsec-performance anti-replay window-size <valor>

Uma janela maior pode ser relevante quando os pacotes são fortemente reordenados em caminhos paralelos. Não é um switch geral de throughput. O valor 0 remove a proteção anti-replay e não é recomendado como solução. Esse teste requer uma janela isolada, uma indicação explícita do Sophos Support e rollback imediatamente disponível.

O limite de cookies IKEv2 protege SAs semiabertas

Segundo a Sophos, a validação de cookies está sempre ativa e só existe para IKEv2. cookie_threshold não a liga nem desliga. Quando o número de IKE SAs simultaneamente semiabertas ultrapassa o limite, o responder solicita um cookie ao initiator. O estado de estabelecimento fica assim protegido contra carga DoS. O default documentado é 30.

set vpn ipsec-performance cookie_threshold <numero>

Um valor menor ou maior só deve ser escolhido com base na carga IKE real e no diagnóstico do suporte. Não corrige Child SAs ausentes, proposals incompatíveis ou falhas de autenticação. Durante a validação são observadas novas ligações IKEv2, strongswan.log, carga de CPU e acessos simultâneos legítimos.

Utilizar o endereço resolvido do peer apenas no caso Charon documentado

use-resolved-ip-address destina-se a muitos túneis IPsec site-to-site com peers FQDN e resolução DNS lenta. Segundo a Sophos, esta combinação específica pode bloquear um thread charon. Com enable, a firewall utiliza o endereço já resolvido em vez de iniciar o túnel repetindo a resolução do FQDN remoto.

set vpn ipsec-performance use-resolved-ip-address enable
set vpn ipsec-performance use-resolved-ip-address disable

O FQDN já tem de ter sido resolvido com sucesso. O default documentado é Off. A opção não substitui DNS funcional, TTL adequados ou resolvers acessíveis. Antes da ativação, correlacionam-se tempo de resolução, respostas A e AAAA atuais, número de túneis e charon.log. Depois de uma mudança de DNS ou provider, confirma-se que a firewall utiliza o novo endereço do peer no tempo esperado. Sem o caso Charon descrito, a definição permanece desativada.

Compatibilidade L2TP, MTU e PPTP

set vpn contém também protocolos de autenticação para L2TP e PPTP e o MTU L2TP global. Isto não torna o PPTP adequado a novos ambientes. PPTP é obsoleto e não deve ser implementado de novo. L2TP Remote Access também continua a ser uma solução de compatibilidade controlada, não o standard preferido para novos clientes geridos.

Primeiro lê-se a configuração atual com show vpn configuration. Para L2TP e PPTP estão disponíveis ANY, CHAP, MS_CHAPv2 e PAP:

set vpn l2tp authentication <ANY|CHAP|MS_CHAPv2|PAP>
set vpn pptp authentication <ANY|CHAP|MS_CHAPv2|PAP>

O valor não é escolhido apenas pelo nome que parece mais forte. Cliente, servidor de autenticação e método VPN configurado em Authentication > Services têm de suportar o mesmo protocolo. Com Active Directory, a combinação suportada pode diferir de um caminho RADIUS. ANY não melhora a segurança, mas alarga os métodos aceites e exige uma decisão de risco consciente.

O MTU L2TP pode ser definido entre 576 e 1460; o default documentado é 1410:

set vpn l2tp mtu <576-1460>

O MTU L2TP não altera uma interface IPsec site-to-site route-based ou policy-based. Só deve ser ajustado gradualmente perante um problema reproduzível de fragmentação L2TP. Depois devem continuar a funcionar transferências grandes e pequenas, DNS, autenticação e nova ligação.

Testar e repor de forma controlada

Em cada janela de manutenção altera-se exatamente um valor global. Antes e depois usam-se os mesmos túneis, fluxo de teste e transição WAN ou HA. Para IPsec registam-se estado do túnel, Child SA, contadores, strongswan.log, charon.log, CPU e Packet Loss. Para a limpeza de sessões incluem-se VoIP, DNS e outros fluxos UDP.

Um ping com sucesso não é uma validação completa. Verificam-se pelo menos um fluxo existente, uma ligação nova, ambas as direções e um teste negativo controlado. Depois relê-se o estado com o comando show vpn ... adequado.

Se a melhoria esperada não ocorrer ou surgirem novas interrupções, define-se exatamente o valor anotado antes do teste. Em seguida voltam a verificar-se túnel e tráfego. Sem estado inicial conhecido, acesso de gestão independente e sintoma fundamentado, não se executa nenhuma alteração set vpn.

FAQ