Sophos Firewall v22 MR3: IPsec e 16 correções

A Sophos lançou o Sophos Firewall OS 22.0 MR3 Build 576 em 16 de outubro de 2026. Após as novas funcionalidades da v22 MR2, o foco está numa atualização de manutenção mais pequena: as notas de versão oficiais apresentam 16 problemas corrigidos. Foi também acrescentada uma nova opção de configuração para IPsec site-to-site com equipamentos de outros fabricantes.

No planeamento da atualização, importa sobretudo saber que serviços são utilizados em cada firewall. Um local com vários extremos VPN exige testes de aceitação diferentes dos de uma firewall com Mail Protection ou de um cluster HA. Por isso, o MR3 deve ser avaliado em função da configuração existente e instalado numa janela de manutenção planeada.

IPsec com outros fabricantes: túnel estabelecido, mas sem tráfego

O MR3 acrescenta um comando que permite desativar as verificações estritas de políticas para IPsec site-to-site. Esta opção responde ao comportamento de equipamentos remotos que utilizam a mesma Security Association (SA) para vários pares de sub-redes. Esta situação podia levar à rejeição de tráfego de entrada quando este não correspondia à SA esperada.

De forma simplificada, uma SA descreve os parâmetros de segurança de uma ligação IPsec. Assim, o facto de um túnel estar estabelecido não prova, por si só, que todas as redes previstas conseguem comunicar entre si. Sobretudo quando existem várias redes locais e remotas, os testes de aceitação devem abranger todas as combinações necessárias.

A nova opção não justifica desativar preventivamente a verificação em todo o lado. Primeiro, deve recorrer-se à resolução de problemas de IPsec para determinar se os sintomas correspondem realmente a um problema de associação à SA. O encaminhamento, as regras de firewall e o NAT continuam a ser causas possíveis de um túnel sem tráfego de dados. O nosso artigo da base de conhecimento Definições globais de VPN descreve a sintaxe, o âmbito e a utilização controlada de ipsec-strict-policy-check na secção sobre a verificação estrita de políticas IPsec.

Para obter resultados fiáveis, os testes devem estabelecer ligações em ambos os sentidos. As capturas de pacotes e os contadores dos túneis envolvidos ajudam a distinguir entre ausência de tráfego de entrada, pacotes rejeitados e falta de um caminho de retorno.

As correções mais relevantes para a operação

Os pontos seguintes são uma seleção das notas de versão oficiais:

• NC-186809, HA: a sincronização de certificados podia tornar o WebAdmin e o VPN Portal inacessíveis.
• NC-186075, rede: as portas RJ45 perdiam temporariamente a ligação com determinados switches.
• NC-182635, Application Control: atualizações repetidas dos caminhos das aplicações provocavam uma carga elevada de CPU.
• NC-181808, RED: entradas RED_DEVICE_DROP obsoletas bloqueavam o tráfego após uma nova implementação.
• NC-183979, e-mail: um spool de correio volumoso prolongava o reinício durante a atualização para o MR2.
• NC-180464, DNAT: o tráfego SMTP era rejeitado incorretamente após uma atualização.
• NC-184117, STAS: os utilizadores já autenticados recebiam novamente o pedido de início de sessão do Captive Portal.
• NC-182222, SSL VPN: os nomes de utilizador numéricos impediam as ligações após a atualização para o MR1.

As restantes entradas dizem respeito a filtros de utilizadores, erros de Syslog, criação de AP VXLAN, desativação de HA, IPsec, bases de dados de assinaturas e relatórios PDF.

Na prática, esta lista deve dar origem a um conjunto breve de testes de aceitação adaptado a cada local. Em HA, estes devem incluir a acessibilidade da interface de administração e do VPN Portal, bem como o estado da sincronização. Nos locais com RED, deve testar-se uma aplicação real através da ligação. Num gateway de correio, a entrega de mensagens de entrada e de saída e o estado da fila são mais esclarecedores do que um ping bem-sucedido.

Também nos problemas de CPU vale a pena comparar o comportamento antes e depois, sob uma carga semelhante. Uma correção correspondente nas notas de versão é um indício, mas ainda não prova que a causa de um incidente concreto tenha sido identificada.

O Config Studio 2.7 facilita alterações específicas

Em paralelo com o firmware, a Sophos apresenta o Config Studio 2.7. Esta ferramenta autónoma, executada no browser, permite apresentar alterações específicas e exportá-las em XML ou TAR. Os pedidos à API também podem ser limitados aos objetos adicionados, alterados e removidos. Inclui ainda correções na comparação de configurações, no assistente de exceções Web e no cálculo de túneis SD-WAN.

A vantagem é particularmente evidente na revisão: um conjunto reduzido de alterações é mais fácil de verificar do que uma exportação completa da configuração. Ainda assim, antes de importar, deve verificar-se que objetos dependentes já têm de existir no sistema de destino. Uma exportação reduzida não substitui uma cópia de segurança nem a verificação funcional posterior. O nosso artigo sobre o Config Studio 2.6 explica as funcionalidades já disponíveis.

O nosso artigo da base de conhecimento Planear uma atualização de firmware descreve a preparação, incluindo o percurso de atualização, a cópia de segurança e a janela de manutenção. Os passos no WebAdmin e através do Sophos Fusion, bem como a verificação posterior e o rollback, encontram-se em Efetuar uma atualização de firmware da Sophos Firewall.