Sophos XG vs. XGS: diferenças, EOL e migração

A série XGS é, desde 2021, a sucessora da série XG. A comparação entre hardware antigo e novo já não se limita ao desempenho. Os últimos modelos XG Series chegaram ao End of Life em 31 de março de 2025; alguns modelos mais antigos já eram EOL. Além disso, SFOS 21.0 e linhas de firmware posteriores já não suportam hardware XG e SG-Series.

Assim, a pergunta real já não é XGS vale a pena?, mas sim Como se planeia corretamente a transição de XG sem ignorar routing, VPN, Central Firewall Reporting ou localizações remotas?

Resposta curta

XG e XGS correm ambas Sophos Firewall OS, mas já não são plataformas equivalentes.

• Lifecycle: XG: End of Life. XGS: plataforma de hardware com suporte ativo.
• Firmware: XG: nenhuma versão SFOS a partir da 21.0. XGS: linhas SFOS atuais, incluindo 22.0.
• Desempenho: XG: plataforma antiga com menos margem para Inspection moderna. XGS: arquitetura Xstream; a aceleração disponível depende do modelo, firmware e caminho de dados.
• Operação: XG: limite de migração e suporte. XGS: plataforma standard para novos projetos de hardware.
• Planeamento: XG: substituição necessária. XGS: Sizing, Port-Mapping e transferência de licença devem ficar definidos antes do cutover.

Uma XG já não deve, por isso, ser vista como um modelo normal de firewall, mas como uma plataforma legada a substituir. Para questões de licença e lifecycle, ver adicionalmente o calendário Sophos Product Lifecycle.

O que End of Life significa na operação de firewall

End of Life em hardware de firewall não é uma entrada formal numa tabela. Uma firewall está no perímetro da rede, termina VPNs, filtra tráfego Web e de aplicações, protege serviços publicados e contém muitas vezes configurações sensíveis. Quando essa plataforma deixa de ser mantida, surge um risco operacional real.

Para uma XG produtiva, estes pontos são especialmente críticos:

• Novas linhas de firmware SFOS já não podem ser usadas.
• A Sophos avisa que as atualizações de software terminam pouco depois do EOL; o suporte do fabricante e a substituição de hardware deixam assim de ser planeáveis com fiabilidade.
• Novas funções, como funcionalidades atuais de VPN, logging, Health Check ou segurança, chegam a plataformas suportadas.
• Licenças, RMA, dispositivos de substituição e casos de suporte tornam-se mais difíceis de planear.
• Auditorias e ciberseguradoras podem avaliar criticamente a continuação da operação de uma firewall EOL.

Isto é particularmente crítico em firewalls com Remote Access VPN ativo, Site-to-Site VPN, WAF, TLS Inspection, Web Protection, servidores publicados ou WebAdmin amplamente acessível. Nestes ambientes, a continuação da operação de uma XG deve ser apenas uma solução transitória limitada no tempo, com plano de migração documentado.

As três diferenças mais importantes

XG e XGS podem parecer semelhantes por fora, consoante o modelo, mas diferem claramente em termos técnicos e operacionais.

• Lifecycle e firmware: o hardware XG está End of Life. SFOS 21.0, 21.5 e 22.0 já não suportam hardware XG e SG-Series. XGS é a plataforma de hardware suportada para versões SFOS atuais.
• Arquitetura e desempenho: XGS usa a arquitetura Xstream e aceleração dependente do modelo. Isto dá mais margem para funções de segurança atuais, VPN, TLS Inspection, IPS, Web Protection e routing. A ficha técnica do modelo específico continua a ser a referência.
• Migração e operação: a mudança para XGS é um projeto de migração. Compatibilidade de backup, Port-Mapping, estado de licenças, HA, SD-WAN, Central Firewall Reporting, RED, Access Points e ZTNA Gateways têm de ser verificados.

Arquitetura: Xstream em vez da antiga plataforma XG

A série XGS foi construída para a arquitetura Xstream, especialmente relevante quando as funções de proteção estão ativas. Porém, os caminhos de dados acelerados e os recursos disponíveis variam entre modelos desktop, 1U e 2U; o nome da série, por si só, não indica throughput. Muitas instalações XG antigas foram ainda dimensionadas com menos TLS Inspection, cloud traffic, SD-WAN e carga de Remote Access.

Consoante o modelo, uma XGS Appliance traz mais reserva para:

• IPS, Web Protection e Application Control.
• TLS Inspection e rollouts maiores de certificados/CA.
• IPsec VPN, SSL VPN, SD-WAN e vários uplinks WAN.
• Mais utilizadores, sessões e regras simultâneos.
• Novas funções SFOS que já nem sequer estão disponíveis em XG.

Nem todos os caminhos de dados ficam automaticamente mais rápidos só porque se instala uma XGS Appliance. Sizing errado, modelos demasiado pequenos, TLS Inspection mal planeada ou arquitetura VPN pouco clara também podem travar uma firewall nova. Para escolher o modelo de destino adequado, o Sophos Firewall Sizing Guide é mais importante do que uma simples comparação 1:1 de modelos.

Quando uma XG deve ser substituída

A substituição de uma XG não deve ser planeada apenas quando um firmware upgrade bloqueia ou uma avaria de hardware já cria pressão. O mais tardar perante estes sinais, é necessário um projeto de migração:

• A firewall deve ser atualizada para SFOS 21.0, 21.5, 22.0 ou mais recente.
• Existem Remote Access VPN, WAF, serviços publicamente acessíveis ou vários Site-to-Site VPNs.
• Suporte, auditoria, RMA ou renovação de licença já não podem ser representados de forma limpa.
• A XG existente está no limite sob IPS, Web Protection, TLS Inspection ou carga VPN.
• RED, Access Points, SD-WAN, Central Firewall Reporting ou ZTNA dependem da firewall existente.
• Um cluster HA, redesenho de portas ou mudança de provider já está previsto.

Se uma XG ainda estiver produtiva, devem documentar-se primeiro um backup atual, o Secure Storage Master Key e a versão de firmware usada. O procedimento está descrito com mais detalhe no artigo Criar ou restaurar um backup da Sophos Firewall.

Planear a migração de XG para XGS

Numa migração de XG para XGS, não se deve escolher apenas o modelo aparentemente mais próximo. É mais útil fazer um breve levantamento antes da janela de manutenção:

• Que portas WAN, LAN e DMZ são efetivamente usadas?
• Existem casos especiais de HA, stacks VLAN, RED, SD-WAN ou VPN?
• Que funções de segurança estão ativas hoje e quais deverão ser ativadas adicionalmente no futuro?
• Que cenários IPsec, SSL-VPN, Sophos-Connect ou ZTNA estão produtivos?
• Existem Central Firewall Reporting, gestão através do Sophos Fusion ou SD-WAN Connection Groups?
• Existem Access Points ou dispositivos SD-RED ligados a esta firewall?
• Existem rotas estáticas, endereços Alias-IP, regras DNAT ou publicações WAF que tenham de estar imediatamente acessíveis após a mudança?
• A plataforma de destino deve voltar a ser hardware ou uma appliance virtual ou cloud?

Definir o percurso de firmware antes do backup

A XG não pode ser atualizada para SFOS 21.0 ou 22.0. A Sophos distingue por isso o restore pela versão da XG de origem; na XGS Appliance de destino, Backup-Restore Assistant requer SFOS 20.0 MR2 ou posterior:

• Com 19.5 MR4 ou qualquer versão 20.0, crie diretamente o backup e mapeie as interfaces durante o restore com Backup-Restore Assistant.
• Com 19.5 MR3 ou anterior, a migração é possível, mas o assistente não aparece. A Sophos recomenda primeiro atualizar a XG para 19.5 MR4 ou 20.0 MR2 e posterior, desde que esse passo intermédio ainda seja suportado e operacionalmente aceitável.

O Setup Assistant da nova XGS Appliance atualiza o destino para a versão mais recente que oferece. Se a mudança também introduzir SFOS 22, leia o guia de atualização de firmware da Sophos Firewall antes da janela de manutenção. Uma configuração legacy Remote Access IPsec bloqueia atualizações para 22.0 MR1 e posterior; legacy CLI VLAN tagging em bridge interfaces bloqueia 22.0 MR2 e posterior, e backups que o contenham também não podem ser restaurados para 22.0 GA ou posterior. O SFOS 22 pode ainda exigir espaço adicional em disco e altera o comportamento de VPNs IPsec policy-based.

Recomendação Avanet: combine a mudança de hardware e uma alteração major de firmware na mesma janela apenas depois destas verificações. Caso contrário, uma falha deixa por esclarecer se a causa foi o backup, Port-Mapping ou firmware.

Backup-Restore Assistant e Port-Mapping

O Port-Mapping e o Backup-Restore Assistant devem ser planeados para os appliances exatos de origem e destino: nomes e número de portas, módulos Flexi Port, variantes wireless e modelos de destino nem sempre correspondem 1:1. Os módulos Flexi Port XG não são compatíveis com XGS e têm de ser substituídos por módulos XGS adequados.

Na prática, deve preparar-se uma tabela de portas antes do restore:

• De Port1 para Port1 na LAN: verifique VLANs, DHCP e DNS.
• De Port2 para Port2 na WAN: verifique Gateway, Alias-IP e NAT.
• De Port3 para Port4 na DMZ: verifique Firewall Rules, WAF e DNAT.
• Flexi Port para um módulo novo: verifique Uplink, Trunk e compatibilidade do módulo.

O assistente só mostra portas físicas. As interfaces VLAN e alias seguem a Parent Interface; LAGs e bridges são recriados a partir dos membros físicos mapeados. Interfaces associadas não mapeadas podem tornar-se pseudo ports. Verifique, além do número da porta, Zone, IP Assignment, Link Mode, Parent Interface e associação.

Os modelos wireless têm limites adicionais. Ao restaurar um backup XG Wireless ou XGS Wireless Gen.1 num modelo XGS Wireless Gen.2, a Sophos exige, entre outros pontos, WPA2 ou posterior, nenhum TKIP, nenhuma interface wireless em bridges físicas e no máximo oito SSIDs únicos entre LocalWiFi0 e LocalWiFi1. Um restore para um modelo sem WLAN integrada exige remover as redes wireless antes do backup. Trate essa alteração como passo separado e verificado, não como improviso durante o cutover.

Se o endereço MAC WAN mudar, routers a montante ou CPEs do provider ainda podem manter entradas ARP antigas. Perante esses sintomas, o artigo Resolver problema ARP na Sophos Firewall após migração ajuda.

Tratar HA separadamente

Um cluster HA XG não é simplesmente substituído por restore para duas novas XGS Appliances. Se um backup HA for restaurado numa nova XGS Appliance sem HA, o restore não recria a configuração HA; esta tem de ser configurada manualmente. Igualdade de modelo, firmware, licenças, porta HA, monitoring, passphrase, troca de papéis e janela de teste exigem um procedimento separado, por exemplo Configurar Sophos Firewall High Availability.

Atualizar Sophos Fusion, Reporting, SD-WAN e ZTNA

Após o restore, a nova XGS Appliance não fica automaticamente integrada de forma igual em todas as funções Sophos Fusion. Consoante o ambiente, é necessário:

• registar a nova firewall em Sophos Fusion,
• verificar Firewall Management e Central Firewall Reporting,
• atribuir ao dispositivo de substituição a licença Central Firewall Reporting separada e os respetivos dados; os relatórios locais da XG não são transferidos,
• para SD-WAN Connection Groups, eliminar primeiro na XGS Appliance as regras e túneis criados pelo Sophos Fusion com prefixo Central_ e depois adicioná-la ao grupo,
• mudar ZTNA Gateways para a nova firewall,
• testar atribuição de SD-RED e Access Points; se a XG ficar ligada em paralelo, eliminar nela a configuração SD-RED e aceitar os Access Points na XGS Appliance,
• rever notificações, backups e relatórios agendados.

Para setups de reporting, ver adicionalmente Ativar Central Firewall Reporting. Para evidências operacionais após a migração, Testar regra da Sophos Firewall com Log Viewer e Packet Capture e Analisar pacotes descartados na Sophos Firewall são mais úteis do que um simples teste de ping.

Erros típicos em migrações XG-para-XGS

Modelo de destino demasiado pequeno

Um modelo sucessor aparentemente adequado pode ser pequeno demais se, desde a aquisição original da XG, tiverem sido adicionados mais utilizadores, mais VPNs, mais TLS Inspection, mais Web Protection ou mais largura de banda. Por isso, não se deve comparar apenas modelo XG contra modelo XGS, mas sim considerar carga real, funções de proteção ativas e crescimento.

Port-Mapping verificado apenas de forma superficial

Se LAN, WAN, DMZ, VLAN-Trunks, portas HA ou ligações de provider forem ligados de forma diferente, um restore bem-sucedido não basta. Após o restore, Interface-Zones, Gateways, SD-WAN Routes, regras NAT, regras WAF e Firewall Rules têm de ser verificados de forma direcionada.

Firmware antigo ou backup antigo

Um backup muito antigo aumenta o risco de Interface-Mapping, certificados, VPNs ou configurações especiais migrarem de forma inesperada. Antes da mudança, deve colocar-se a firewall antiga, na medida em que ainda faça sentido e seja suportado, numa versão adequada e criar um backup recente.

Sistemas dependentes esquecidos

Muitas migrações não falham no restore, mas sim em sistemas dependentes: Monitoring, Syslog, SIEM, e-mails de backup, VPN clients, ARP do provider, DNS, DHCP, RED, Access Points ou Sophos Fusion. Estes pontos pertencem à checklist, não à investigação de erros depois da comutação.

Checklist antes da mudança

• Firmware atual da XG e firmware de destino da XGS Appliance documentados.
• Compatibilidade de restore dos modelos exatos de origem e destino verificada na ferramenta Sophos.
• Backup atual criado e palavra-passe de restore guardada em segurança.
• Secure Storage Master Key atual e, se aplicável, anterior, além da palavra-passe do backup, disponíveis de forma segura e separada.
• Port-Mapping preparado para WAN, LAN, DMZ, VLAN-Trunks e HA.
• Flexi Ports XG substituídos por módulos XGS compatíveis; restrições wireless verificadas.
• Transferência de licença, registo no Sophos Fusion e estado de suporte verificados.
• Para SFOS 22: legacy IPsec, CLI VLAN tagging, espaço em disco e VPNs IPsec policy-based verificados.
• VPNs, NAT, WAF, SD-WAN, DHCP, DNS e routing preparados como lista de teste.
• RED, Access Points, ZTNA, Central Firewall Reporting e Monitoring considerados.
• Plano de rollback definido com dispositivo antigo, plano de cabos e janela de manutenção.
• Contactos para provider, DNS, monitoring e aplicações disponíveis.

Rollback com um limite de interrupção claro

Mantenha a XG antiga inalterada, desligada ou fisicamente isolada, e disponível com um plano de cablagem etiquetado até à aceitação. Antes do cutover, defina uma hora e critérios de interrupção mensuráveis: WAN Gateway inacessível, publicação DNAT crítica indisponível ou túnel VPN essencial ainda down após o período reservado para diagnóstico.

Para o rollback, isole a XGS Appliance, reponha a cablagem na XG conforme o plano e só então ligue a XG. Volte a verificar WAN, routing, VPN e serviços publicados. As alterações feitas durante o teste da XGS Appliance não estão automaticamente na XG antiga; registe-as e avalie-as após o rollback. Não faça reset nem retire a XG antes de a XGS Appliance ser aceite como estável, ter backup e estar documentada.

Verificação após a migração

Depois da comutação, não se deve verificar apenas se a Internet funciona. Uma migração limpa só está concluída quando as funções operacionais mais importantes foram validadas:

• Verificar Dashboard, estado de licença, registo no Sophos Fusion e e-mail de backup.
• Testar WAN-Gateway, endereços Alias-IP, NAT e serviços publicados.
• Verificar Site-to-Site VPN, Remote Access VPN e perfis Sophos Connect.
• Controlar SD-WAN Routes, rotas estáticas e Route Precedence.
• Testar Firewall Rules com logging.
• Verificar por amostragem IPS, Web Protection, TLS Inspection e Application Control.
• Controlar ligações RED e Access Point.
• Testar Syslog, Central Firewall Reporting, notificações e Monitoring.
• Retirar a XG antiga de operação apenas após uma fase estável.

Se alguns destinos não estiverem acessíveis imediatamente após a migração, deve trabalhar-se sistematicamente com Log Viewer, Packet Capture e verificações de routing. Para o diagnóstico de base, ajudam Usar Sophos Firewall Packet Capture no WebAdmin e Alterar Route Precedence na Sophos Firewall com segurança.

FAQ