Como migrar de outro firewall para o FortiGate sem interrupção de serviço

Princípio fundamental: nunca migre sem validar

O maior erro em projetos de migração de firewall é tentar fazer tudo de uma vez — substituir o firewall antigo pelo novo em uma única janela de manutenção, sem validação prévia das políticas no novo equipamento.

A abordagem correta é paralela e incremental: o FortiGate novo é instalado em paralelo com o firewall antigo, as políticas são configuradas e validadas no novo sem impactar a produção, e a migração efetiva é feita com o novo equipamento já testado e o antigo como fallback imediato.

Fase 1: levantamento e documentação

Antes de configurar qualquer coisa no FortiGate, documente completamente o ambiente atual:

Inventário de políticas: exporte todas as políticas do firewall atual com comentários sobre a finalidade de cada uma. Políticas sem documentação e sem hits recentes são candidatas a não serem migradas — aproveite a migração para limpar regras obsoletas.

Mapeamento de NAT: documente todos os mapeamentos de NAT — IPs públicos, portas publicadas, servidores de destino. Esses são os itens que mais causam incidentes se esquecidos durante a migração.

VPNs ativas: liste todos os túneis VPN — site-to-site e de acesso remoto — com os parâmetros de cada um (IKE version, encryption, DH group, pre-shared keys ou certificados).

Rotas estáticas: documente todas as rotas estáticas configuradas no firewall atual. Em ambientes sem BGP/OSPF, rotas estáticas esquecidas causam black holes de tráfego pós-migração.

Fase 2: configuração e validação em paralelo

Com o FortiGate instalado em paralelo (sem ser o gateway padrão ainda), configure todas as políticas, NATs e VPNs baseando-se na documentação levantada. Use este período para também implementar melhorias que não eram possíveis no firewall anterior — segmentação de VLANs, perfis de segurança mais granulares, inspeção SSL.

Ferramenta de conversão: a Fortinet oferece a ferramenta FortiConverter que automatiza a conversão de políticas de Cisco ASA, Check Point e outros fabricantes para o formato FortiGate. Ela não faz uma conversão perfeita — especialmente em políticas complexas — mas reduz significativamente o trabalho manual.

Validação de políticas: use o recurso Policy Lookup do FortiGate para simular como pacotes específicos seriam tratados pelas políticas configuradas. Teste todos os fluxos críticos antes de mudar o gateway padrão.

Fase 3: migração efetiva

Com o FortiGate validado em paralelo, a migração efetiva é uma operação de mudança de gateway — rápida e com risco controlado:

1. Janela de manutenção: agende para horário de menor impacto. Comunique todos os times afetados com pelo menos 48 horas de antecedência.

2. Snapshot / backup: faça backup completo do firewall atual e do FortiGate antes de iniciar a janela.

3. Mudança de gateway: altere o default gateway dos switches de core e servidores para apontar para o FortiGate. Se o IP do gateway muda, atualize também as entradas de DHCP e as configurações estáticas dos servidores.

4. Teste imediato: valide conectividade para internet, acesso a servidores críticos, VPNs site-to-site e acesso remoto nos primeiros 15 minutos após a mudança.

5. Rollback em caso de problema: se algo crítico não funcionar e não puder ser corrigido rapidamente, reverta o gateway para o firewall antigo. Com o firewall antigo ainda operacional e configurado, o rollback leva menos de 5 minutos.

Fase 4: estabilização e descomissionamento

Após a migração, mantenha o firewall antigo em standby por pelo menos 2 semanas — tempo suficiente para identificar qualquer aplicação ou serviço que não esteja funcionando corretamente no novo ambiente.

Use os logs do FortiGate nesse período para identificar tráfego bloqueado que deveria ser permitido (aplicações que não foram mapeadas no levantamento) e tráfego permitido que talvez não devesse ser (políticas muito amplas que foram migradas sem refinamento).

Somente após 2 semanas sem incidentes não resolvidos o firewall antigo deve ser desligado e descomissionado.