Resolver problemas de ARP no Sophos Firewall após migração

Após uma migração de firewall, pode acontecer que o novo Sophos Firewall esteja geralmente online, mas endereços IP públicos individuais ou endereços IP de alias não estejam acessíveis. Isso é especialmente típico após uma troca de outro fabricante para o Sophos Firewall ou após uma migração de hardware XG para XGS. Os endereços IP permanecem os mesmos, mas o endereço MAC na interface WAN muda.

Se um roteador anterior, um CPE do provedor ou um switch ainda tiver entradas ARP antigas no cache, ele continuará enviando pacotes para o endereço MAC anterior. Isso faz parecer que apenas certos endereços IP de alias, destinos DNAT ou testes de ping não funcionam. Para o planejamento geral da migração, consulte também o artigo Qual é a diferença entre um firewall XG e XGS?.

Sintomas típicos

Problemas de ARP após uma mudança geralmente se manifestam imediatamente após a troca ou após uma restauração em novo hardware.

Indicações típicas:

A interface WAN do Sophos Firewall está online.
O endereço IP principal funciona, mas endereços IP de alias individuais não.
O ping para determinados IPs públicos falha, enquanto outros IPs na mesma interface respondem.
Regras DNAT ou WAF parecem configuradas corretamente, mas não alcançam o servidor interno.
Um serviço é acessível internamente, mas externamente apenas em determinados IPs públicos está com problemas.
Após algum tempo, funciona de repente, pois um cache ARP expira automaticamente.

É importante delimitar: nem todo problema de acessibilidade após uma migração é um problema de ARP. Regras de firewall, regras NAT, zonas, configuração de alias, roteamento do provedor e rotas de retorno também devem ser verificadas.

Por que o ARP pode causar problemas após uma migração

O ARP resolve endereços IPv4 em endereços MAC. Em um segmento local de camada 2, um dispositivo pergunta: Qual endereço MAC pertence a este endereço IP? A resposta é armazenada no cache ARP para que cada pacote não precise acionar uma nova consulta ARP.

Em uma migração de firewall, o endereço IP geralmente permanece o mesmo, mas o endereço MAC muda. Isso pode ser problemático:

O roteador do provedor ainda conhece o IP público com o endereço MAC antigo.
Um switch ou roteador anterior mantém entradas ARP desatualizadas.
Um IP de alias foi configurado corretamente no novo firewall, mas o vizinho continua enviando para o hardware antigo.
Apenas parte dos IPs foi reaprendido, por isso alguns endereços funcionam e outros não.

Para endereços IP de alias individuais, isso é particularmente irritante, pois a conexão básica parece funcionar. Rapidamente se verifica NAT, regras de firewall ou roteamento, embora o erro já ocorra antes na camada 2.

Verificar antes do comando CLI

Antes de acionar ativamente o ARP, a configuração básica deve estar correta. Caso contrário, um ARP-ping apenas encobrirá outro problema.

Verifique:

Em Network > Interfaces, verifique se o endereço IP ou endereço IP de alias afetado está na interface correta.
Verifique a zona da interface, por exemplo, WAN.
Verifique o gateway, máscara de sub-rede e lógica de rede de alias.
Em Rules and policies > NAT rules, verifique se a regra DNAT aponta para o IP público correto.
Em Rules and policies > Firewall rules, verifique se existe uma regra adequada para o tráfego.
No Log Viewer, veja se os pacotes estão chegando ao firewall.
Se necessário, use o Sophos Firewall Packet Capture no WebAdmin para verificar se os pacotes de entrada são visíveis na interface WAN.

Se no Packet Capture não chegarem pacotes para o IP público afetado, o problema provavelmente está antes do firewall: roteador do provedor, switch anterior, cache ARP ou roteamento no provedor. Se os pacotes chegarem, mas forem descartados, deve-se primeiro verificar NAT, regras de firewall e zonas. Para lógica de interface e zonas, consulte Configurar zonas e interfaces do Sophos Firewall.

Executar ARP-Ping através da Device Console

O Sophos Firewall pode acionar um ARP-ping com IP de origem e interface definidos através da Device Console. Isso é útil quando um IP de alias deve ser ativamente anunciado na rede após a migração.

Importante: O comando deve ser executado apenas quando estiver claro qual IP de origem, qual interface e qual destino no segmento local serão usados. Valores incorretos não ajudam e podem distorcer a análise. Antes de fazer alterações em uma migração produtiva, deve haver um Backup do Sophos Firewall atualizado.

O comando é executado na Device Console, não no Advanced Shell:

system diagnostics utilities arp ping source <alias-ip> interface <interface> <target-ip>

Exemplo:

system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1

Neste exemplo, 198.51.100.21 é o IP de alias afetado em Port2. 198.51.100.1 é um destino acessível no mesmo segmento de camada 2, tipicamente o gateway upstream ou o CPE do provedor. Isso faz com que o firewall gere tráfego ARP com o IP de origem correto através da interface correta.

Se o SSH ainda não estiver configurado, Conectar ao Sophos Firewall via SSH descreve como acessar a Device Console. Em migrações, o SSH não deve ser amplamente permitido a partir do WAN de forma permanente. É melhor um acesso administrativo temporário e restrito a partir de uma rede confiável.

Procedimento recomendado

1. Coletar endereços IP afetados

Primeiro, documente quais endereços IP funcionam e quais não. Para endereços IP de alias, deve-se comparar diretamente a lista com a configuração da interface.

Anotar:

Interface, por exemplo, Port2
Endereço IP principal e endereços IP de alias
Gateway upstream ou CPE do provedor
Regras NAT ou WAF afetadas
Resultado de ping, teste de porta e Packet Capture

2. Delimitar problema de ARP

De um sistema de teste externo, verifique o IP público afetado. Paralelamente, inicie o Packet Capture no Sophos Firewall na interface WAN.

Interpretação:

Nenhum pacote chega à interface WAN: Verifique upstream, ARP, roteamento do provedor ou dispositivo anterior.
Pacotes chegam, mas são descartados: Verifique regra de firewall, NAT, zona ou serviço.
Pacotes chegam e seguem internamente, mas falta resposta: Verifique rota de retorno, servidor interno, SNAT ou firewall do servidor.
Apenas IP de alias afetado, IP principal funciona: Verifique especificamente cache ARP ou configuração de alias.

3. Executar ARP-Ping por IP de alias afetado

Para cada IP de alias afetado, execute o ARP-Ping com o IP de origem apropriado e a interface correta. Depois, não altere imediatamente várias outras coisas, mas teste primeiro se o comportamento muda.

Exemplo com espaços reservados:

system diagnostics utilities arp ping source <betroffene-alias-ip> interface <wan-interface> <upstream-gateway>

Se vários endereços IP de alias forem afetados, o comando é executado individualmente por endereço. Isso torna a verificação rastreável e evita que no final não se saiba qual medida ajudou.

4. Validar acessibilidade

Após o ARP-Ping, repita o mesmo teste:

Ping ou teste de porta TCP de fora.
Packet Capture na interface WAN.
Filtrar Log Viewer para o IP de destino afetado.
Verificar regra NAT e de firewall se os pacotes agora chegam.

Se o upstream aprender corretamente a informação ARP, os pacotes para o IP de alias agora devem chegar ao novo firewall. Se o serviço publicado funcionar depois disso, depende adicionalmente de NAT, regras de firewall, servidor interno e caminho de retorno.

Se o ARP-Ping não ajudar

Se o ARP-Ping não trouxer melhorias, não deve-se experimentar comandos adicionais arbitrariamente. Uma delimitação estruturada é então sensata.

Outras verificações:

Dispositivo upstream pode ainda manter entradas ARP desatualizadas.
Provedor deve recarregar cache ARP ou CPE.
IP de alias está na interface errada ou em uma rede errada.
IP público é roteado pelo provedor em vez de aprendido diretamente no segmento local via ARP.
Regra DNAT aponta para o endereço público errado.
Regra de firewall não permite o tráfego.
Servidor interno responde por outro gateway.
Em HA ou troca de hardware, o endereço MAC errado foi esperado.

Reiniciar o CPE do provedor ou um roteador anterior pode limpar caches ARP, mas não deve ser a primeira medida. Em ambientes produtivos, é mais limpo primeiro coletar evidências com Packet Capture e Log Viewer.

Envolver especificamente o provedor ou upstream

Se na interface WAN não chegarem pacotes para o IP público afetado, a solicitação ao provedor ou responsáveis pelo upstream deve ser o mais concreta possível. Uma mensagem geral como “o firewall não está acessível” muitas vezes leva a ciclos desnecessários. Melhor é uma breve prova técnica que mostra qual IP está afetado e o que foi verificado no Sophos Firewall.

Informações úteis:

IP público ou IP de alias afetado: O provedor pode verificar especificamente a entrada ARP ou de roteamento.
Interface WAN e novo endereço MAC: Mostra qual associação é esperada após a migração.
Gateway upstream ou endereço CPE: Delimita qual dispositivo vizinho deve aprender o endereço.
Momento do teste ARP-Ping: Facilita a comparação com logs do provedor ou status do CPE.
Resultado do Packet Capture: Comprova se os pacotes chegam ao Sophos Firewall.
Regra DNAT e de firewall verificada: Evita que o caso seja rapidamente classificado como problema de regra local. O endereço MAC da interface WAN pode ser documentado na interface WebAdmin em Network > Interfaces. Se o provedor precisar limpar um cache ARP ou recarregar um CPE, isso deve ser relacionado ao IP específico ou à interface afetada. Um reinício geral de todos os dispositivos envolvidos só é sensato se a responsabilidade, janela de manutenção e impacto forem claros.

Lista de verificação

Endereços IP principais e de alias afetados documentados.
Interface, zona, gateway e configuração de alias verificados.
Regras NAT e de firewall para o IP afetado verificadas.
Packet Capture mostra se os pacotes chegam à interface WAN.
ARP-Ping executado apenas com IP de origem, interface e IP de destino corretos.
Acessibilidade externa testada novamente após cada alteração.
Se necessário, provedor ou responsáveis pelo upstream contatados com IP específico, endereço MAC, momento do teste e observação do Packet Capture.

FAQ

É necessário atualizar manualmente o ARP após cada migração de firewall?

Não. Em muitos ambientes, dispositivos vizinhos aprendem automaticamente o novo endereço MAC. Medidas manuais de ARP são principalmente relevantes quando endereços IP individuais não estão acessíveis após a troca, embora a configuração do firewall pareça correta.

É um problema de NAT ou de ARP?

Se os pacotes no Packet Capture não chegarem à interface WAN, o NAT no Sophos Firewall ainda não é o primeiro suspeito. Se os pacotes chegarem, mas não forem encaminhados, deve-se verificar NAT, regras de firewall, zonas e caminhos de retorno internos.

Por que o IP principal funciona, mas um IP de alias não?

O upstream pode ter aprendido entradas ARP diferentes por endereço IP. Portanto, um IP pode já apontar corretamente para o novo endereço MAC, enquanto outro ainda aponta para o firewall antigo.

Deve-se simplesmente reiniciar roteadores ou switches?

Apenas se a intervenção for operacionalmente viável e a responsabilidade estiver clara. É melhor primeiro uma verificação direcionada: Packet Capture no Sophos Firewall, status ARP no dispositivo upstream e, se possível, limpeza direcionada do cache ARP no dispositivo afetado.

É necessário usar o Advanced Shell para isso?

Não. O ARP-Ping mostrado é executado na Device Console do Sophos Firewall. Advanced Shell não é necessário para isso e deve ser evitado para verificações de migração simples.