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. As opções 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 compilação do SFOS, hora, túneis afetados, fluxo de teste esperado e um acesso de gestão independente. Criar também uma cópia de segurança atual da configuração. A ajuda CLI do SFOS 22 só documenta set vpn para estes valores, não um comando de leitura. Os registos de alterações e as cópias de segurança são elementos de apoio, mas não comprovam o valor atualmente ativo. O Sophos Support deve confirmar um método para ler o valor exato na compilação instalada. Antes da alteração, registar o resultado e preparar o comando set vpn de reposição correspondente. Se o Support não puder confirmar um método de leitura ou se não for possível determinar o valor atual, interromper o procedimento e não alterar a definição global.

A ajuda do SFOS 22 só indica defaults para MTU L2TP, anti-replay, limite de cookies e endereço resolvido do peer. Nem mesmo estes defaults provam que o appliance específico mantém uma configuração inalterada.

A reposição utiliza sempre o valor inicial determinado em segurança. A sintaxe documentada não tem um parâmetro default universal. Os comandos de valores predefinidos apresentados abaixo só são adequados quando a alteração pretende regressar explicitamente ao valor predefinido documentado do SFOS 22; não podem substituir um valor inicial intencionalmente personalizado.

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

Uma possível finalidade de conn-remove-tunnel-up é a limpeza das ligações existentes quando se estabelece um túnel IPsec. As ajudas do SFOS 22 e do SFOS 23 comparadas listam o parâmetro, mas não descrevem separadamente este efeito exato. Antes de qualquer alteração, o Sophos Support tem de confirmar o efeito e a sintaxe para a compilação instalada; sem essa confirmação, a opção permanece inalterada. 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. A ajuda do SFOS 22 não documenta um default; por isso, repor o valor determinado em segurança antes da alteração.

As duas linhas são alternativas, não uma sequência. Para a alteração, escolher exatamente uma linha com o valor de destino justificado. Para o rollback, executar separadamente apenas a linha que repõe o valor inicial previamente determinado em segurança; a outra linha não constitui um caminho de reposição automático.

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.

As duas linhas são alternativas, não uma sequência. Para a alteração, escolher exatamente uma linha com o valor de destino justificado. Para o rollback, executar separadamente apenas a linha que repõe o valor inicial previamente determinado em segurança; a outra linha não constitui um caminho de reposição automático.

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

A ajuda do SFOS 22 não indica um default para nenhuma das definições conn-remove-*. O rollback repõe exatamente o valor inicial documentado.

Em HA, cada protocolo deve ser testado separadamente. Segundo a ajuda HA do SFOS 22, os túneis IPsec route-based, policy-based e remote access são repostos no failover. Para tráfego dentro do túnel IPsec, o failover de sessão suporta UDP e ICMP, mas não TCP. conn-remove-* não substitui o design HA nem um teste com um fluxo TCP e UDP existente.

Distinguir definições com âmbitos diferentes

• Perfil IPsec: Use strict profile e Pass data in compressed format em System > Profiles > IPsec profiles só se aplicam às ligações com esse perfil. A ajuda do perfil associa strict profile a problemas de handshake causados por fragmentação e indica que a compressão ocorre antes da encriptação. Não são definições globais.
• SSL VPN: Remote access VPN > SSL VPN > SSL VPN global settings aplica-se a todas as policies SSL VPN remote access e ao ficheiro .ovpn. A ajuda SSL VPN indica para Disconnect dead peer after os defaults 180 segundos em TCP e 100 em UDP; em UDP são permitidos 60-110. Disconnect idle peer after é indicado em minutos, sem default documentado. Estes valores não se aplicam a IPsec ou L2TP.
• Fontes de autenticação SSL VPN: A ajuda da API para o SFOS 22 e 23 distingue três opções em SSLVPNAuthenticationMethods: SameAsVPN herda as fontes de autenticação configuradas para a VPN, SameAsFirewall herda as fontes configuradas para a firewall e Custom utiliza servidores de autenticação selecionados especificamente. Para esta lista personalizada de servidores, AuthenticationServer está documentado como um array opcional de cadeias de caracteres que admite vários valores. O exemplo das fontes coloca as entradas sob SSLVPNAuthenticationServerList, dentro de SSLVPNAuthentication. Esta seleção não é um timeout de SSL VPN nem o valor de protocolo L2TP/PPTP descrito abaixo. A ajuda não comprova a ordem dos servidores, o fallback, um valor predefinido ou o comportamento de uma lista de servidores quando as fontes são herdadas; por isso, não se deduz aqui qualquer exemplo XML executável.
• L2TP na administração Web: Remote access VPN > L2TP > L2TP global settings aplica-se a todas as políticas L2TP e controla ativação, intervalo de concessão, concessão RADIUS, DNS, WINS e membros. O intervalo documentado deve ser privado, pertencer a uma sub-rede /24 ou menor e conter no máximo 254 endereços. A Sophos afirma que os intervalos L2TP e PPTP não se podem sobrepor às configurações de acesso remoto IPsec ou SSL VPN; esta página não afirma que os intervalos L2TP e PPTP não se podem sobrepor entre si. A autenticação via CLI descrita abaixo aplica-se a L2TP e PPTP; o MTU definido via CLI continua a ser específico do L2TP.
• Valores globais da firewall: tcp-est-idle-timeout, udp-timeout, udp-timeout-stream e fragmented-traffic de set advanced-firewall não são definições VPN. A ajuda CLI indica 2700-432000 segundos para TCP estabelecido, 30-3600 para cada timeout UDP e allow como default do tráfego fragmentado. Não devem ser alterados para um único túnel.

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 Sophos não documenta um default para ipsec-max-workqueue-items. O rollback utiliza set vpn ipsec-performance ipsec-max-workqueue-items <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 é uma opção geral para aumentar o débito. As ajudas do SFOS 22 e do SFOS 23 comparadas listam 0, mas não explicam o seu efeito na proteção anti-replay. Não utilizar este valor como solução para um problema sem que o Sophos Support tenha confirmado o efeito e as consequências de segurança para a compilação instalada. Esse teste requer uma janela isolada, uma indicação explícita do Sophos Support e rollback imediatamente disponível.

set vpn ipsec-performance anti-replay window-size 1024 repõe o default documentado. Se o valor inicial era personalizado, repor exatamente esse valor.

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.

set vpn ipsec-performance cookie_threshold 30 repõe o default documentado. Um limite personalizado é reposto com a mesma sintaxe.

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.

As duas linhas são alternativas, não uma sequência. Para a alteração, escolher exatamente uma linha com o valor de destino justificado. Para o rollback, executar separadamente apenas a linha que repõe o valor inicial previamente determinado em segurança; a outra linha não constitui um caminho de reposição automático.

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; set vpn ipsec-performance use-resolved-ip-address disable repõe-no. Se enable era o valor inicial registado, usá-lo em alternativa como rollback personalizado. A opção não substitui DNS funcional ou resolvers acessíveis. Antes da ativação, correlacionam-se tempo de resolução, endereço resolvido do peer, 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.

Verificação estrita de políticas IPsec

A ajuda CLI atual do SFOS 22 documenta ipsec-strict-policy-check como uma opção separada de set vpn, não como parte de ipsec-performance. As Security Associations (SAs) são as associações de segurança do tráfego IPsec protegido. Com enable, o Sophos Firewall valida o par de sub-redes face à SA associada; o tráfego IPsec de entrada que não corresponde à SA esperada pode ser descartado. Não é Use strict profile em System > Profiles > IPsec profiles, que trata problemas de handshake causados por fragmentação no âmbito do perfil.

Considerar disable apenas para o caso de compatibilidade documentado: um peer de outro fabricante utiliza SAs partilhadas para vários pares de sub-redes em túneis IPsec site-to-site. Isto desativa a verificação estrita da associação. Falhas genéricas de túnel, routing ou autenticação não o justificam; primeiro é necessário comprovar que se aplica exatamente este caso de SAs partilhadas.

Antes de definir o valor: são necessários um acesso de gestão independente, uma cópia de segurança atual e um método de leitura do valor ativo confirmado pelo Sophos Support para a compilação instalada. Registar previamente o resultado, o valor atual e a reposição exata desse valor inicial. Sem um método de leitura fiável ou um valor atual determinado em segurança, não alterar a definição.

A sintaxe documentada para 4. Device Console é:

set vpn ipsec-strict-policy-check [enable | disable]

Os parênteses retos indicam alternativas: substituí-los apenas pelo valor de destino justificado, enable ou disable. A ajuda atual do SFOS 22 não fornece nem um valor predefinido nem um getter/comando de leitura para esta opção. Por isso, não se apresenta aqui qualquer comando de default, reset ou leitura inventado. As notas de versão apresentam esta opção como novidade do SFOS 22.0 MR3 Build 576 de 16 de outubro de 2026. A sua menção na ajuda geral do SFOS 22 não comprova a disponibilidade em builds 22.0 anteriores; essa disponibilidade não pode ser pressuposta nessas builds.

Numa janela de manutenção controlada, alterar apenas este valor global. Antes e depois, testar os pares de sub-redes afetados e os túneis até então não afetados, com fluxos existentes e novos em ambas as direções. Os testes negativos controlados de tráfego devem também confirmar que o tráfego não permitido continua bloqueado; investigar associações SA e motivos de rejeição com as verificações IPsec e de captura de pacotes da secção de testes e reposição abaixo. Voltar a ler o valor de destino com o método confirmado pelo Support. Se não houver melhoria ou surgirem regressões, repor exatamente o valor inicial registado com a mesma sintaxe e voltar a lê-lo; depois verificar novamente os túneis e o tráfego dos utilizadores. Os quatro comandos de valores predefinidos do SFOS 22 abaixo não repõem esta definição.

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.

Para L2TP e PPTP estão disponíveis ANY, CHAP, MS_CHAPv2 e PAP:

Escolher apenas a linha correspondente ao protocolo a alterar e substituir o marcador por exatamente um token suportado pelo cliente e pela fonte de autenticação: ANY, CHAP, MS_CHAPv2 ou PAP. Não executar ambas as linhas como uma sequência. O rollback repõe exclusivamente o token desse protocolo determinado previamente.

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

A seleção das fontes de autenticação VPN em Authentication > Services responde a uma questão diferente da do valor de protocolo da CLI: que fontes verificam a autenticação e, para esse efeito, a VPN herda a seleção da firewall ou utiliza servidores de autenticação selecionados especificamente? A ajuda da API para o SFOS 22 e 23 descreve a reutilização da autenticação da firewall e documenta AuthenticationServer como um array opcional de cadeias de caracteres que admite vários valores de servidores. Daqui não se pode concluir nada sobre a ordem ou o fallback. Em contrapartida, ANY, CHAP, MS_CHAPv2 e PAP selecionam o método de autenticação para L2TP ou PPTP, respetivamente; não selecionam uma lista de servidores.

Sem exemplo executável de modo da API VPN: Nas duas ajudas da API comparadas, o exemplo das fontes para VPNAuthenticationMethods apresenta os valores SameAsFirewall e Custom, enquanto a linha resumida de parâmetros obrigatórios da tabela apenas admite on e off. Esta contradição não permite determinar um valor de modo cuja execução seja fiável. Por isso, este artigo não inclui qualquer instrução de API nem exemplo XML para esse efeito. A explicação acima apenas distingue as fontes de autenticação do protocolo da CLI; não é um guia de configuração do portal do utilizador.

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.

A Sophos não documenta um default para estes dois valores CLI. O rollback utiliza o token inicial registado com a mesma sintaxe, por exemplo set vpn l2tp authentication MS_CHAPv2 se esse era o valor inicial.

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.

set vpn l2tp mtu 1410 repõe o default documentado. Se o MTU inicial tinha sido personalizado intencionalmente, repor antes esse valor registado.

Testar e repor de forma controlada

As quatro linhas seguintes mostram exemplos independentes dos valores predefinidos do SFOS 22 explicitamente documentados, não uma sequência: não executar o bloco completo. Para um rollback, escolher apenas a linha do parâmetro alterado, e apenas se o seu valor inicial previamente determinado em segurança era exatamente esse valor predefinido. Caso contrário, definir exclusivamente o valor inicial exato registado, utilizando a mesma sintaxe; os restantes parâmetros permanecem inalterados.

set vpn ipsec-performance anti-replay window-size 1024
set vpn ipsec-performance cookie_threshold 30
set vpn ipsec-performance use-resolved-ip-address disable
set vpn l2tp mtu 1410

A Sophos não indica defaults para conn-remove-*, ipsec-max-workqueue-items nem para os dois protocolos de autenticação. Uma configuração personalizada é sempre reposta com o valor anotado antes do teste e a mesma sintaxe set vpn.

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 um fluxo existente, uma ligação nova, ambas as direções e um teste negativo controlado. Current activities > IPsec connections mostra IPsec e Current activities > Remote users os utilizadores SSL VPN. A referência de registos associa IPsec a strongswan.log, ipsec_monitor.log e charon.log, SSL VPN a sslvpn.log e L2TP a l2tpd.log. Diagnostics > Packet capture mostra as interfaces de entrada e saída, o ID da regra, o estado e o motivo da rejeição; utilizar um filtro restrito para os pontos finais de teste anonimizados, evitando a recolha de dados não relacionados. Depois da alteração, verificar o valor de destino com o método de leitura confirmado pelo Support. A aceitação do comando e o tráfego observado, por si só, não comprovam qual é o valor global ativo.

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. Após o rollback, voltar a ler o valor inicial reposto com o método de leitura previamente confirmado pelo Support e compará-lo com a baseline registada; em seguida, verificar novamente os túneis e o tráfego dos utilizadores.

FAQ