Saltar para o conteudo
Avanet

Sophos Firewall: diagnosticar sistematicamente uma VPN IPsec

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.

As definições avançadas globais, como limpeza de sessões em failover, janela anti-replay, limite de cookies IKEv2 ou utilização de endereços peer já resolvidos, não devem ser alteradas como primeira tentativa de diagnóstico. Utilizar em segurança as definições VPN globais explica o efeito, a verificação inicial e o rollback.

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.

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.

Antes do diagnóstico pela CLI, Current activities > IPsec connections mostra apenas as ligações IPsec atualmente estabelecidas. A lista pode ser filtrada por Connection name, Local server name, Local subnet, Username, Remote server/host ou Remote subnet e atualizada com Refresh. Disconnect termina ativamente a ligação selecionada e não é uma atualização inofensiva: primeiro documentar a hora e o estado e só depois desligar numa janela de teste planeada. Este instantâneo não substitui a verificação de Child SA, logs e tráfego.

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, /termo-de-pesquisa procura dentro do ficheiro.

Depuração do StrongSwan

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

service -S | grep strongswan

Se a saída já indicar um estado de depuração ativo, não voltar a executar o comando de comutação. Primeiro, identificar quem o ativou e com que finalidade; a sequência seguinte só se aplica se estava inicialmente inativo. O texto exato pode variar consoante a compilação.

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

Se a depuração não estiver ativa, executar o comando uma vez e verificar o novo estado:

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

Depois, acompanhar strongswan.log num segundo terminal, reproduzir o problema exatamente uma vez e terminar tail com Ctrl+C:

tail -f /log/strongswan.log

Por fim, executar uma vez o mesmo comando de comutação. A segunda linha deve confirmar o restabelecimento do estado normal sem depuração registado anteriormente:

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.

O Local ID de um lado deve corresponder ao Remote ID do outro e vice-versa. Comparar primeiro os IDs e o PSK guardado em ambos os lados. Se for necessário alterar o PSK, coordenar a operação nos dois peers durante uma janela de manutenção; espaços invisíveis e cópias a partir de gestores de palavras-passe são causas frequentes. Um ID incorreto pode impedir a correspondência do peer antes da verificação do PSK esperado.

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 a zero ou não aumentarem, 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.

O Packet Capture utiliza um buffer limitado e para quando este fica cheio. A vista mostra, entre outros campos, Rule ID, NAT ID, Status e Reason. Durante uma captura normal, o tráfego FastPath acelerado é geralmente encaminhado temporariamente pelo SlowPath. Verificar o estado do buffer, o filtro e o momento do teste antes de interpretar uma captura vazia ou interrompida como prova de ausência de tráfego.

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 cria as rotas VPN no backend. Estas não aparecem na vista normal de routing. As IPsec Route manuais e a Route Precedence podem ser consultadas na Device Console:

system ipsec_route show
system route_precedence show

A ordem predefinida é static, sdwan_policyroute, vpn. A ausência de uma entrada na vista normal não prova, portanto, um erro de routing. Para o fluxo de teste, correlacionar Diagnostics > Tools > Route lookup, o log da firewall e o Packet Capture.

Em IPsec route-based, o caminho depende do tipo de interface XFRM:

  • Any/Any ou Dual: a interface XFRM tem endereços IP. Uma rota estática, SD-WAN ou dinâmica deve encaminhar para ela o tráfego remoto.
  • Traffic Selectors específicos: o SFOS cria automaticamente a rota estática. Não é possível atribuir um endereço IP ou uma rota adicional à interface XFRM.

Verificar a interface em Network > Interfaces e o caminho em Diagnostics > Tools > Route lookup. A Device Console mostra as rotas estáticas configuradas:

show static-route

Verificar os estados XFRM no Advanced Shell:

ip xfrm state
ip xfrm policy

Se várias ligações utilizarem as mesmas redes locais e remotas como caminhos alternativos, a seleção e o failover devem ser explícitos. Colocar as ligações policy-based e as route-based com Traffic Selectors específicos no mesmo grupo de failover IPsec. Os túneis XFRM Any/Any podem, em alternativa, comutar através de rotas SD-WAN; o procedimento associado explica a ordem, o Health Check e o teste controlado.

Verificar NAT por tipo de túnel

O NAT é permitido, mas não substitui uma rota. Verificar primeiro se o caminho do destino original ou traduzido seleciona o túnel correto e depois se o ponto remoto espera os endereços efetivamente utilizados.

Se as redes local e remota forem idênticas, uma única indicação sobre SNAT não é suficiente. Utilizar NAT em redes IPsec sobrepostas descreve o processo espelhado completo de endereçamento, túnel, regras e routing.

  • 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: a interface XFRM tem um endereço IP e requer uma rota explícita. Determinar se e como ocorre a tradução a partir da regra NAT correspondente e do Packet Capture, sem a deduzir apenas do tipo de túnel.
  • Route-based com Traffic Selectors específicos: o SFOS cria automaticamente a rota e não atribui um endereço IP à interface XFRM. Pressupor MASQ para um suposto IP XFRM não é, portanto, um método de diagnóstico fiável; verificar antes a Source original, a Source traduzida e o NAT Rule ID correspondente.

Documentar a Source original e a Source traduzida, permiti-las no ponto remoto e assegurar o 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.
  • 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 Respin Build 411 ou MR1 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, repor o estado registado antes do teste. Se a acceleration estava ativa, utilizar:

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 apenas a depuração do StrongSwan ativada durante este procedimento. Não alterar um estado preexistente sem conhecer o responsável e a finalidade. 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.