Saltar para o conteudo
Avanet

Resolução de Problemas de VPN IPsec no Sophos Firewall

Sophos Firewall

Na resolução de problemas de IPsec, a ordem é essencial: primeiro verificar IKE e a Child SA, depois as regras de firewall, NAT, roteamento e caminho de retorno. Um túnel verde confirma apenas a negociação, não o funcionamento do tráfego útil.

Para um novo túnel, consulte primeiro Configurar VPN IPsec Site-to-Site no Sophos Firewall. Os passos seguintes aplicam-se a uma ligação já configurada.

Procedimento de diagnóstico

  1. O túnel permanece inativo: Verificar a versão IKE, o perfil IPsec, o gateway, as IDs Local/Remote, o PSK ou o certificado em strongswan.log.
  2. A Fase 1 está estabelecida, mas não existe Child SA: Comparar os Traffic Selectors, a proposta da Fase 2, o PFS e as sub-redes.
  3. O túnel está verde: Usar ipsec statusall para verificar se a SA está ESTABLISHED, se a Child SA está INSTALLED e se os contadores de bytes aumentam.
  4. Apenas uma direção contabiliza bytes: Verificar regras de firewall, NAT, roteamento e, em particular, o caminho de retorno no ponto remoto.
  5. A causa continua incerta: Acompanhar um único fluxo de teste com Log Viewer e Packet Capture.
  6. A firewall falha repetidamente com multicast através de VPN: Não provocar o problema com mais testes de carga. Registar a versão do firmware, os timestamps e os dados de diagnóstico disponíveis; NC-180433 foi corrigido no SFOS 22.0 MR2 Build 546.

Antes disso, bastam alguns valores documentados: nome do túnel, IP ou FQDN do peer, versão IKE, IDs Local/Remote, redes locais e remotas, tipo policy-based ou route-based, perfil IPsec e um teste com Source, Destination e Service. Exemplo: túnel azure-vpn, rede local 172.16.10.0/24, rede remota 10.20.30.0/24.

Em IPsec policy-based, as redes fazem parte da negociação. IPsec route-based utiliza uma interface XFRM e rotas estáticas, SD-WAN ou dinâmicas. Se o caminho estiver incorreto, consulte os guias específicos sobre Rotas IPsec e Route Precedence.

⚠️ Os logs e Packet Captures podem conter endereços IP públicos, redes internas, nomes de host ou conteúdo dos pacotes. Recolhê-los apenas de forma direcionada e por tempo limitado, e verificá-los antes de os partilhar.

Verificar logs e CLI

Em Site-to-site VPN > IPsec, Show additional properties mostra, entre outros, Local subnet, Remote subnet, Gateway type e Profile. Em Profiles > IPsec profiles, também é possível comparar diretamente os valores da Fase 1 e da Fase 2.

Os ficheiros mais importantes em /log são:

  • strongswan.log: IKE, autenticação e Child SAs
  • charon.log: daemon IKE
  • ipsec_monitor.log: monitorização do serviço IPsec
  • /log/ipsec_conn/ipsec_<connectionname>.log: ações Connect, Activate e Deactivate no WebAdmin
  • xfrmi.log: interfaces XFRM
  • dgd.log: Dead Gateway Detection e failover de VPN

A atual lista central de logs do SFOS 22 indica ipsec_monitor.log. Uma página de resolução de problemas mais antiga da Sophos ainda indica strongswan-monitor.log; para sistemas SFOS 22 atuais, prevalece a lista de logs mais recente.

No Advanced Shell, é possível acompanhar ou filtrar o log principal em tempo real. Se o acesso por SSH e ao shell ainda não for familiar, consulte Resolução de Problemas de CLI no Sophos Firewall: comandos importantes.

cd /log
tail -f /log/strongswan.log
tail -f /log/strongswan.log | grep -i azure-vpn
less /log/strongswan.log
grep -i "no proposal" /log/strongswan.log

Estas linhas são alternativas, não um procedimento contínuo. Em less, /suchbegriff procura dentro do ficheiro.

Debug do StrongSwan

Se o log normal não for suficiente, verificar primeiro o estado atual no Advanced Shell:

service -S | grep strongswan

Se já aparecer RUNNING,DEBUG, não voltar a executar o toggle como se fosse uma ativação. Utilizar o debug já ativo e desativá-lo depois conforme descrito abaixo.

⚠️ Manter o debug ativo apenas por pouco tempo. Pode gerar rapidamente ficheiros de log de grande dimensão e ocupar espaço de armazenamento.

Se o debug ainda não estiver ativo, executar o toggle, verificar o novo estado e reproduzir o erro exatamente uma vez:

service strongswan:debug -ds nosync
service -S | grep strongswan
tail -f /log/strongswan.log

Para strongswan, deve aparecer RUNNING,DEBUG. Em seguida, o mesmo comando volta a desativar o modo de debug; o segundo comando confirma o retorno ao estado anterior:

service strongswan:debug -ds nosync
service -S | grep strongswan

Verificar o estabelecimento do túnel

Fase 1: IKE, IDs e autenticação

Se o túnel não for estabelecido, normalmente a versão IKE, o gateway, as IDs, a proposta, o PSK ou o certificado não correspondem.

  • no IKE config found ou Remote peer is refusing our Phase 1 proposals: A firewall não encontra uma ligação adequada ou o perfil não corresponde. Verificar a versão IKE, Listening Interface, endereço do peer, IDs Local/Remote e o perfil.
  • peer authentication failed, AUTH_FAILED, AUTHENTICATION_FAILED, no matching peer config found ou Remote peer reports we failed to authenticate: As IDs e a autenticação não correspondem à configuração esperada do peer.
  • invalid HASH_V1 payload length ou decryption failed: Em IKEv1, é frequentemente um PSK incorreto; em IKEv2, aparece mais frequentemente AUTH_FAILED.
  • O ponto remoto alcança outro endereço público ou UDP 500/4500 não é encaminhado corretamente por NAT, router ou fornecedor.
  • Com certificados, a cadeia de certificados, a CA emissora, a validade ou a ID esperada não correspondem.

Se um certificado tiver sido revogado antes de expirar ou o efeito da revogação continuar incerto, verifique em conjunto o issuer, o número de série, thisUpdate, nextUpdate e a rejeição específica do serviço. O procedimento seguro encontra-se em Importar e testar Certificate Revocation Lists na Sophos Firewall.

A Local ID de um lado deve corresponder à Remote ID do outro e vice-versa. O PSK deve ser novamente definido em ambos os lados; espaços invisíveis ou copiar e colar a partir de gestores de palavras-passe são causas frequentes. Uma ID incorreta pode impedir a associação ao peer antes mesmo de o PSK esperado ser verificado.

Fase 2: Traffic Selectors e Child SA

Se a Fase 1 estiver estabelecida, mas não existir Child SA, normalmente as sub-redes ou os valores da Fase 2 são diferentes.

  • traffic selectors ... inacceptable
  • failed to establish CHILD_SA
  • received traffic selectors didn't match
  • Remote peer reports INVALID_ID_INFORMATION
  • valores diferentes em TSi e TSr
  • NO_PROPOSAL_CHOSEN após Phase 1 is up e Initiating establishment of Phase 2 SA

NO_PROPOSAL_CHOSEN isoladamente não é suficiente para classificar o problema: antes da Fase 1, aponta para valores de IKE/Fase 1; depois de uma Fase 1 bem-sucedida, aponta para ESP, PFS ou outros valores da Fase 2.

Para comparar todos os campos de General settings, Phase 1, Phase 2 e DPD, consulte Compreender e configurar perfis IPsec na Sophos Firewall.

As redes devem estar configuradas de forma espelhada. Se a Sophos espera localmente 172.16.10.0/24 e remotamente 10.20.30.0/24, o ponto remoto deve propor 10.20.30.0/24 para 172.16.10.0/24. Mesmo um /24 de um lado e um único host do outro, ou objetos de host mantidos de forma diferente, podem impedir a Child SA.

O túnel está estabelecido, mas não passa tráfego

No Advanced Shell, este comando mostra SAs, redes negociadas e contadores de bytes:

ipsec statusall

Os valores importantes são ESTABLISHED, INSTALLED e os contadores nas duas direções. Se ambos permanecerem vazios, o tráfego de teste provavelmente não chega ao túnel. Se apenas o lado de saída aumentar, normalmente falta o caminho de retorno ou uma regra no ponto remoto; se apenas os bytes de entrada aumentarem, deve-se suspeitar da rota local, da regra local ou do sistema de destino.

Acompanhar um fluxo de teste

Um teste restrito é mais útil do que vários pings em paralelo:

  • Source IP: 172.16.10.25
  • Destination IP: 10.20.30.15
  • Service: ICMP ou TCP 443
  • direção esperada: LAN para VPN
  • regra esperada: LAN_to_VPN_Branch

Depois, verificar nesta ordem:

  1. Ativar Log firewall traffic na regra afetada.
  2. Filtrar o Log Viewer por Source, Destination e Rule ID.
  3. Iniciar Packet Capture com host 172.16.10.25 and host 10.20.30.15.
  4. Executar o teste exatamente uma vez.
  5. Comparar a regra, a NAT Rule ID, o encaminhamento, a resposta e os contadores de bytes.
  6. Verificar no ponto remoto a rota de retorno, a regra remota e o sistema de destino.

Se nenhum pacote chegar ao Sophos Firewall, a causa está antes dele, por exemplo no gateway do cliente, VLAN ou roteamento local. Se chegar mas não for encaminhado, existe uma incompatibilidade na regra, no NAT, na rota ou numa Security Feature. O procedimento completo está em Verificar uma regra de firewall com Log Viewer, Policy Test e Packet Capture.

Roteamento e XFRM

Em IPsec policy-based, o SFOS 22 mantém as rotas VPN no backend. As Rotas IPsec manuais e a Route Precedence são verificadas na Device Console:

system ipsec_route show
system route_precedence show

O comando conhecido de procedimentos de diagnóstico mais antigos no Advanced Shell não é uma prova fiável de um túnel policy-based no SFOS 22:

ip route show table 220

No SFOS 22, as rotas VPN policy-based e as entradas manuais ipsec_route não estão visíveis nessa tabela. A ausência de uma entrada não prova, portanto, nem a falta de uma rota nem um erro de roteamento.

Em IPsec route-based, deve existir uma rota estática, SD-WAN ou dinâmica para a interface XFRM, bem como estados XFRM adequados. Verificar a interface XFRM em Network > Interfaces e o caminho em Diagnostics > Tools > Route lookup; a Device Console mostra as rotas estáticas configuradas:

show static-route

Os estados XFRM são verificados no Advanced Shell:

ip xfrm state
ip xfrm policy

As interfaces XFRM não podem utilizar redes de transferência sobrepostas. As ligações com sub-redes locais e remotas idênticas devem pertencer ao mesmo grupo de failover IPsec ou utilizar uma lógica de seletores e roteamento claramente diferente. O procedimento associado explica a ordem do grupo, Health Check e o teste de comutação controlado.

Verificar NAT por tipo de túnel

NAT é permitido, mas deve corresponder ao tipo de túnel e aos endereços que o ponto remoto espera.

  • Policy-based com SNAT: A regra SNAT pretendida requer Outbound interface Any. A regra SNAT predefinida com portas WAN específicas não corresponde ao tráfego IPsec policy-based.
  • Route-based com Any/Any ou Dual: MASQ traduz a Source para o IP XFRM; este aparece no cabeçalho IP interno no Packet Capture.
  • Route-based com Traffic Selectors específicos: Se uma regra MASQ corresponder, a firewall descarta o tráfego porque não existe um endereço IP atribuído a essas interfaces XFRM.

A Source original e a Source traduzida devem estar documentadas, permitidas no ponto remoto e incluídas no respetivo caminho de retorno. NAT no Sophos Firewall explica os fundamentos e a ordem das regras.

Instabilidade e casos especiais do SFOS 22

Se o tráfego parar apenas mais tarde, comparar os timestamps no estado do túnel, em strongswan.log, dgd.log, nos eventos WAN e no teste da aplicação. As causas frequentes são:

  • O produto de terceiros utiliza traffic-based Rekeying; o Sophos Firewall suporta time-based Rekeying.
  • Ambos os lados executam rekey ao mesmo tempo. Escalonar deliberadamente os tempos de vida das chaves da Fase 1 e da Fase 2 no Initiator e no Responder.
  • A interface atribuída foi desativada. Os túneis em modo Initiator desligam imediatamente; as ligações em modo Responder desligam o mais tardar após inatividade ou DPD timeout.
  • Várias ligações com as mesmas sub-redes não pertencem ao mesmo grupo de failover.
  • As transferências grandes falham apesar de um teste pequeno funcionar; nesse caso, verificar MTU e MSS.

Falhas repetidas da firewall com multicast através de VPN

Se as falhas coincidirem com tráfego multicast através de um túnel VPN, registar primeiro a versão e a build do firmware, o túnel afetado, os timestamps e os dados de diagnóstico ou de crash disponíveis. A Sophos confirma este problema como NC-180433 e corrigiu-o no SFOS 22.0 MR2 Build 546.

A descrição pública do problema não indica um tipo de túnel ou uma configuração multicast específicos, nem fornece um workaround de CLI. Numa build anterior do SFOS 22, verificar o caminho de atualização, atualizar para MR2 Build 546 ou para uma versão aprovada mais recente e repetir depois o mesmo tráfego de forma controlada. Não alterar por suposição os parâmetros do túnel, IPsec Acceleration ou os serviços. Se a firewall continuar a falhar com MR2 ou uma versão posterior, fornecer os dados recolhidos ao Sophos Support em vez de continuar a atribuir automaticamente o problema a NC-180433.

A configuração normal e o teste de aceitação controlado são explicados em Multicast Routing na Sophos Firewall; o crash aqui descrito continua a ser um caso específico dependente do firmware.

Os pacotes IKEv2 são fragmentados

No problema conhecido NC-136352, o perfil IKEv2 predefinido pode oferecer tantos grupos DH que os pacotes IKE excedem 1'500 bytes. Se um componente intermédio descartar fragmentos ou informações PMTU, o Initiator envia repetidamente enquanto o Responder não vê nada.

Quando o erro corresponder exatamente a este padrão, verificar o peer no Advanced Shell:

tcpdump -ni any 'host 203.0.113.10 and (udp port 500 or udp port 4500)'

Em seguida, configurar no perfil IPsec apenas o grupo DH efetivamente necessário ou um número significativamente menor de grupos. Sophos Firewall tcpdump descreve filtros tcpdump gerais e a exportação PCAP.

Alias PPPoE e IPsec Acceleration

NC-181526 afeta o SFOS 22.0 GA Build 411 ou MR1 Build 490 em determinadas appliances XGS físicas: o túnel utiliza uma interface de alias de uma porta PPPoE-WAN, está ligado, mas não transporta tráfego útil quando IPsec Acceleration está ativa. Estão excluídos os modelos XGS 88/88w, 108/108w, 118/118w e 128/128w.

A lista atual de problemas conhecidos da Sophos indica SFOS 22.0.2 MR2 Build 546 como versão corrigida; no entanto, NC-181526 não aparece separadamente na lista de correções MR2 publicada. Depois da atualização, deve-se por isso repetir o mesmo fluxo de teste em vez de inferir a correção apenas a partir da versão indicada.

⚠️ A desativação de IPsec Acceleration é global, reinicia todos os túneis IPsec e provoca uma interrupção. Testar apenas numa janela de manutenção e quando a combinação de build, hardware, alias PPPoE e padrão de erro corresponder exatamente.

Os seguintes comandos são executados na Device Console:

system ipsec-acceleration show
system ipsec-acceleration disable
system ipsec-acceleration show

Se não houver melhoria, restaurar o estado inicial:

system ipsec-acceleration enable

O SFOS 22.0 MR2 corrige com NC-180520 um caso semelhante, mas diferente, relacionado com alias IP: com Acceleration ativa, o gateway XFRM podia permanecer inacessível quando ESP entrava por outra porta WAN. As duas Issue IDs não devem ser equiparadas. O SFOS 22 Upgrade Check reúne outras verificações antes e depois da atualização.

Validação e escalamento

Depois de cada alteração, repetir o mesmo fluxo de teste individual e documentar pelo menos estes pontos:

  1. Hora, nome do túnel, IP do peer, Source, Destination e Service
  2. Estado no WebAdmin e ipsec statusall antes e depois do teste
  3. regra de firewall e NAT atribuída
  4. Packet Capture e contadores nas duas direções
  5. rota de retorno e regra remota no ponto remoto
  6. alteração, resultado e rollback preparado

Desativar depois o debug do StrongSwan. Guardar de forma direcionada os logs relevantes para o Sophos Support; Guardar logs do Sophos Firewall descreve a exportação. Verificar pacotes de logs e capturas de maior dimensão quanto a dados sensíveis antes de os partilhar.