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 uma XGS Appliance, 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.

Os bloqueadores acima devem ser distinguidos dos avisos seguintes: NC-177529, NC-181885 e NC-184583 aplicam-se apenas à versão ou função indicada. O caso Let’s Encrypt abaixo é um relato não confirmado, não um bloqueador geral publicado pela Sophos.

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:

Em Backup & Firmware > Firmware, registar primeiro Current firmware e a versão e build do slot ativo. Em Latest available firmware, ou na imagem carregada manualmente, o destino tem de indicar SFOS 22.0 MR2 Build 546. Download apenas descarrega a imagem; Install inicia a mudança de versão. Upload Firmware coloca uma imagem manual no slot inativo, enquanto Upload & Boot reinicia de imediato. Confirmar novamente a build, a ação e o slot ativo antes de clicar. Um aviso nesta página apresenta o campo Reference code.

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 Fusion (anteriormente 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. A lista oficial de Known Issues remete para o Sophos Support para obter o workaround, mas não publica os passos. 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

Segundo as release notes, o MR2 Build 546 suporta as novas CA do Let’s Encrypt YE Root, YE1, YE2, YR Root, YR1 e YR2. Separadamente, dois relatos públicos da Community descrevem uma migração falhada do MR1 Build 490 para o MR2 Build 546 durante a utilização de um certificado Let’s Encrypt, seguida de reversão automática para o MR1. As release notes e a lista pública de Known Issues não confirmam esta relação. Em 5 de setembro de 2026, não existe por isso um issue ID oficial, um teste prévio fiável ou uma versão com correção confirmada.

Antes do upgrade de uma firewall MR1 com um certificado Let’s Encrypt emitido ou renovado recentemente, devem registar-se Issued by e todas as atribuições de serviço em Certificates > Certificates. Um issuer YE/YR ou a simples presença destas CA em Certificates > Certificate authorities não comprova o erro relatado e, por si só, não constitui um bloqueador. O Sophos Support pode avaliar previamente uma firewall crítica específica; sem confirmação oficial, o adiamento do upgrade também continua a ser uma decisão operacional baseada no risco. 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 padrão relatado 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, aceitação e reversão

• Antes: Excluir os bloqueadores, preparar o backup e o SSMK, verificar a sincronização de HA e registar a versão de origem, o slot ativo, a build de destino, os caminhos de VPN, os fluxos de teste e o caminho de reversão.
• Durante: Não efetuar alterações paralelas em routing, VPN ou switching; monitorizar o estado e o HA failover. Depois de voltar a iniciar sessão, confirmar em Backup & Firmware > Firmware que Current firmware apresenta realmente o MR2 Build 546; em HA, verificar também a versão, a função e a sincronização de ambos os nodes.
• Depois: Testar interfaces e WAN, acesso à Internet, DNS, DHCP, Central, HA, STAS, autenticação, regras de firewall, VPN, NAT e serviços publicados com os fluxos predefinidos. O Log Viewer e o Packet Capture devem mostrar os Firewall e NAT Rule IDs esperados.

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.

Definir antes da janela durante quanto tempo pode ser analisada uma indisponibilidade. Se, nesse ponto de decisão, WAN, HA, as VPN centrais ou publicações críticas continuarem instáveis, em Backup & Firmware > Firmware selecionar Boot firmware image para o slot compatível anterior. Esta reversão manual ativa o firmware e o estado de configuração anterior desse slot, podendo perder-se alterações posteriores ao upgrade. Não deve ser planeada para um caminho de upgrade não suportado nem como substituto de backup, SSMK e um caminho de reimage. Após a reversão, testar novamente a versão ativa, HA, WAN, routing, VPN, NAT, DNS, DHCP, Central e logging, e guardar os logs de migração antes de nova tentativa.

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