Verificação de atualização do SFOS 22: confirmar bloqueadores

Antes de uma atualização para o SFOS 22, é necessário confirmar se a plataforma, o caminho de atualização e a configuração suportam a versão de destino. Esta verificação tem em conta o SFOS 22.0 MR2 Build 546 de 14 de julho de 2026 e complementa as instruções gerais para a atualização do firmware do Sophos Firewall.

Bloqueadores estritos de atualização e restauro

• Hardware XG ou SG: O SFOS 22 não é suportado. Em vez de uma atualização, é necessário migrar para XGS, uma plataforma virtual, de software ou cloud.
• Legacy Remote Access IPsec: A partir do SFOS 22.0 MR1, a configuração tem de ser migrada ou removida antes da atualização.
• Legacy CLI VLAN Tagging numa interface Bridge: A partir do SFOS 22.0 MR2, system vlan-tag tem de ser substituído por interfaces VLAN suportadas.
• Backup com Legacy VLAN Tagging: Para um restauro no SFOS 22.0 GA ou posterior, é necessário corrigir a configuração de origem e criar um novo backup.
• Armazenamento ou caminho de atualização: Se a página de firmware indicar pouco espaço de armazenamento ou um caminho de atualização inválido, a causa tem de ser corrigida primeiro.

Se existir um bloqueador ou algum ponto não estiver claro, a atualização não deve ser iniciada.

Caminho de atualização direto para o SFOS 22.0 MR2

Para a versão de destino aqui abordada, SFOS 22.0 MR2 Build 546, a Sophos suporta uma atualização direta a partir das seguintes versões:

• SFOS 22.0: MR1 Build 490 e GA Build 411 ou 365
• SFOS 21.5: MR2 Build 323, MR1 Build 261 ou GA Build 171
• SFOS 21.0: MR2 Build 349, MR1 Build 277, 272 ou 237 e GA Build 169
• Versões anteriores: qualquer versão do SFOS 20.0, 19.5 ou 19.0

⚠️ Se a versão atual não constar desta lista, não se deve confirmar o aviso de migração não suportada. Caso contrário, o firewall reinicia com as definições de fábrica e a configuração atual é perdida. Um backup também só pode ser restaurado a partir de uma versão cuja migração de configuração seja suportada.

Para uma versão anterior ou que não conste da lista, é necessário planear primeiro um caminho intermédio suportado. Além disso, a lista de versões não substitui as restantes verificações: a plataforma, o armazenamento, os componentes legados e o plano de restauro também têm de ser adequados.

Verificações antes da janela de manutenção

Plataforma e componentes legados

• Documentar o modelo e o firmware atual, para que seja possível rastrear o caminho de atualização indicado acima e um eventual restauro.
• Tratar o hardware XG e SG como uma migração, não como uma atualização normal.
• Substituir os túneis SSL VPN do UTM9 e os dispositivos RED 15, RED 15w e RED 50 antes da atualização.
• Em Network > Interfaces, corrigir os nomes que terminam em dez ou mais algarismos. Estes nomes podem ocultar interfaces no WebAdmin após a atualização.

Armazenamento, backup e acesso

A utilização das partições pode ser verificada de forma aproximada na Advanced Shell:

df -kh

Se a página de firmware apresentar um aviso, a atualização ainda não deve ser iniciada. O código de referência indica a causa e o passo seguinte:

• FWDS501: o Primary Disk ou uma das suas partições de sistema é demasiado pequeno para o SFOS 22. Numa VM implementada antes do SFOS 18, a mesma disposição antiga pode manifestar-se inicialmente durante uma atualização para o SFOS 21.5 ou mais recente apenas como um erro genérico de firmware (NC-151465); no entanto, a mensagem, por si só, não prova o erro do disco. Para um firewall virtual, aumentar o Primary Disk antes do SFOS 22 mostra como verificar e aumentar o Hard disk 1 e confirmar depois o resultado. O mesmo artigo contém os valores-limite e as soluções adequados para uma Software Appliance.
• FWDS502: não existe espaço livre suficiente em /var. Em 4. Device Console, system firmware check-disk-space mostra o espaço necessário e as áreas de dados envolvidas. Reports ou logs só devem ser eliminados de forma controlada depois de guardar os dados necessários; o procedimento é descrito em Verificar o espaço e gerir reports.
• FWDS503: a partição /content é demasiado pequena. A Sophos exige um factory reset, com indisponibilidade e perda da configuração atual. Depois de criar um backup recente e guardar o SSMK, deve ser introduzido RESET em maiúsculas na consola série e selecionada a opção 2; isto elimina as configurações próprias e repõe as pattern signatures no estado do firmware ativo. Em seguida, o backup é restaurado e as funções verificadas; só depois é efetuada a atualização. Os reports locais não são restaurados.
• FWDS504: o firmware do SSD está desatualizado e tem de ser atualizado antes da atualização do SFOS.
• FWDS505: a Sophos Support tem de verificar o estado do SSD. Uma verificação SMART local pode documentar valores para o suporte, mas não remove o bloqueio.

Num cluster HA, cada node deve ser verificado separadamente, pois as duas appliances podem apresentar códigos de referência diferentes.

Antes de começar, também devem estar disponíveis:

• um backup recente armazenado externamente e o Secure Storage Master Key correspondente
• acesso de administrador local ou acesso alternativo fora do caminho VPN normal
• um caminho de reversão definido com uma pessoa responsável e um ponto de decisão
• para HA, um cluster saudável e sincronizado, com links HA e Monitored Ports estáveis

Os detalhes sobre backup e restauro encontram-se em Criar ou restaurar um backup do Sophos Firewall.

Configurações de risco especial

Legacy Remote Access IPsec

A partir do SFOS 22.0 MR1, uma configuração existente de Legacy Remote Access IPsec bloqueia a atualização. Primeiro, é necessário migrar os utilizadores, pools e perfis afetados para a configuração atual de Remote Access IPsec, SSL VPN, ZTNA ou outro modelo adequado. O procedimento encontra-se em Migrar Legacy Remote Access IPsec antes do SFOS 22 MR1.

Microsoft Entra ID SSO com Same as firewall

O SFOS 22.0 ou posterior ativa automaticamente o Microsoft Entra ID SSO para o Portal VPN, Acesso Remoto IPsec e SSL VPN quando o respetivo método de autenticação está definido como Same as firewall antes da atualização. Por isso, antes da janela de manutenção documentam-se as definições em Authentication > Services e o fornecedor de identidade realmente esperado.

Após a atualização, verifica-se separadamente cada método efetivo. Se o Entra SSO for pretendido, o VPN portal and remote access URL exato do objeto de servidor Entra tem de constar como Redirect URI na aplicação Entra; o URL reverse SSO do Sophos Central não é adequado para este fim. Um login piloto real verifica o portal, o cliente e o MFA. Se o SSO não for pretendido, define-se expressamente o método desejado. O procedimento completo encontra-se em Configurar o Microsoft Entra ID SSO para a VPN do Sophos Firewall.

Policy-based IPsec e NAT

Os túneis site-to-site policy-based em produção devem ser verificados antes e depois da atualização com um fluxo de teste concreto. Isto inclui Source, Destination, Service, Traffic Selectors, dispositivo remoto e as regras de firewall e NAT esperadas. Em caso de problemas, podem ser consultados Resolução de problemas de VPN IPsec e Compreender NAT no Sophos Firewall.

Antes da atualização, também é necessário determinar se o OSPF ou BGP anunciava anteriormente redes VPN policy-based remotas através de redistribute kernel. A partir do SFOS 22, estas redes já não estão disponíveis como rotas normais do kernel; SFOS 22: rotas IPsec e redistribute kernel mostra que prefixos devem ser verificados antes e depois da atualização e porque um design XFRM route-based se adequa melhor ao routing dinâmico.

SMTP via DNAT

Quando um servidor interno de correio é publicado via DNAT, o plano de manutenção deve incluir vários testes com mensagens reais recebidas, e não apenas um teste de porta. No âmbito de NC-184583, a Sophos lista ligações SMTP interrompidas esporadicamente após uma atualização para o SFOS 22.x; GA Respin Build 411 é explicitamente indicada como versão afetada e não existe um workaround público. A delimitação exata das versões, a recolha de evidências e o escalamento para o suporte estão descritos em Publicar um servidor via DNAT no Sophos Firewall.

Let’s Encrypt e rollback da migração do MR2

O MR2 Build 546 suporta as novas CA do Let’s Encrypt YE Root, YE1, YE2, YR Root, YR1 e YR2. Independentemente disso, em dois upgrades documentados publicamente do MR1 Build 490 para o MR2 Build 546, a migração da configuração foi interrompida em associação com um certificado Let’s Encrypt que estava em utilização. A firewall reverteu automaticamente para o MR1. Após uma verificação através do Support Access, a Sophos confirmou um bloqueio de migração conhecido para certificados emitidos num período específico, mas não delimitado publicamente. Em 9 de agosto de 2026, continua a não existir um issue ID público, um teste prévio fiável ou uma versão com a correção confirmada.

Antes do upgrade de uma firewall MR1 com um certificado Let’s Encrypt emitido ou renovado recentemente, devem documentar-se o Issuer e a atribuição ao serviço em Certificates > Certificates. Um Issuer YE/YR ou a simples presença destas CA em Certificate authorities não comprova o erro de migração e, por si só, não constitui um bloqueio geral do upgrade. Numa firewall crítica, continua a ser aconselhável coordenar previamente o caso com o Sophos Support ou adiar o upgrade enquanto não for confirmado um teste prévio público ou uma correção. Os certificados e as CA não devem ser eliminados nem renomeados com base numa suspeita: uma tentativa de eliminação documentada na Community não resolveu o erro de forma fiável, e o certificado pode proteger WAF, WebAdmin, portais, Hotspot ou SMTP TLS. Gerir certificados na Sophos Firewall explica como verificar as atribuições e preparar uma substituição segura com um caminho de reversão.

Este rollback da migração não é o mesmo erro que uma cadeia de certificados incompleta entregue após a renovação. Certificados Let’s Encrypt na Sophos Firewall descreve a verificação deste segundo problema e o hotfix distribuído para o corrigir.

Após um rollback automático, o comportamento corresponde ao erro conhecido se dbv22.004 e tblvpncertificate_caid_fkey aparecerem em migration.log e a instrução de eliminação envolvente mencionar objetos YE/YR. Estes termos de pesquisa ajudam a encontrar as linhas relevantes:

dbv22.004
tblvpncertificate_caid_fkey
Lets_Encrypt_YE
Lets_Encrypt_YR

Se aparecerem, devem guardar-se migration.log, migrationhash.log, a mensagem do firmware, a hora e as builds de origem e destino, sem repetir o upgrade nas mesmas condições. Em seguida, verificar o firmware de origem, HA, WAN, routing, VPN, a ligação ao Central e todos os serviços dependentes de certificados. Guardar os logs da Sophos Firewall para o Support mostra como preservar as evidências; com estes dados, a Sophos Support pode delimitar o erro de migração.

Legacy VLAN Tagging em Bridges

Legacy CLI VLAN Tagging em interfaces Bridge tem três consequências:

• Em GA e MR1, o tráfego de ou para a firewall pode falhar, enquanto o tráfego de trânsito continua a funcionar.
• A partir do MR2, a atualização é bloqueada.
• Não é possível restaurar um backup afetado no SFOS 22.0 GA ou posterior.

Antes da correção, é necessário documentar Bridge, VLAN IDs, endereços IP, zonas, switch trunks e serviços dependentes. Em seguida, são criadas interfaces VLAN suportadas com Bridge como Parent e é gerado um novo backup. O caso especial é descrito em Verificar as Bridge VLANs do Sophos Firewall antes do SFOS 22.

STAS

Ao atualizar para o MR1, a opção Restrict client traffic during identity probe deve estar definida como No em Authentication > STAS. O MR2 corrige o erro do MR1 e utiliza No como predefinição para novas configurações; ainda assim, devem ser verificados os valores existentes e as regras baseadas em utilizadores. Mais informações encontram-se em Configurar o STAS no Sophos Firewall.

Análise de malware na atualização para GA Build 411

Apenas numa atualização específica para SFOS 22.0 GA Respin Build 411, o NC-177529 pode apresentar temporariamente Malware Unscannable durante a migração, frequentemente para www.msftconnecttest.com, porque o novo motor de análise da Sophos ainda não está disponível. Antes desta atualização GA, mudar de Single engine para Dual engine em Web > General settings e, após a conclusão da atualização, voltar a definir o Single Engine utilizado anteriormente. Esta medida não se aplica de forma geral ao MR1, MR2 ou versões posteriores; o contexto e a escolha do motor de análise são explicados em Configurar e testar a análise de malware no Sophos Firewall.

Janela de manutenção e controlo

• Antes: Excluir os bloqueadores, preparar o backup e o SSMK, verificar a sincronização de HA e documentar os caminhos de VPN, teste e reversão.
• Durante: Não efetuar alterações paralelas em routing, VPN ou switching; monitorizar o estado e o HA failover.
• Depois: Verificar firmware, interfaces, Internet, regras de firewall, VPN, NAT, HA, STAS, DNS, DHCP, Central e Log Viewer.

Um túnel verde ou um Policy Test bem-sucedido ainda não prova que o tráfego dos utilizadores funciona. Por isso, as ligações críticas devem ser verificadas com pacotes reais, Log Viewer, Packet Capture e os valores de Rule ID das regras de firewall e NAT. Em caso de problemas, não se devem alterar várias áreas ao mesmo tempo.

A atualização está concluída quando os testes definidos são bem-sucedidos e a versão de destino, o estado de HA, os resultados dos testes e os trabalhos pendentes estão documentados.

FAQ