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

As VPNs IPsec Site-to-Site geralmente funcionam sem problemas, desde que estejam operacionais. No entanto, se um túnel não se estabelecer, permanecer instável após uma reconexão ou parecer conectado mas não transportar tráfego, é necessário seguir uma sequência clara para a análise. Caso contrário, pode-se facilmente alternar entre PSK, rotas, regras de firewall e logs sem identificar a causa real.

Este artigo explica como verificar sistematicamente as conexões IPsec no Sophos Firewall: primeiro a configuração do túnel, depois as redes negociadas e, por fim, o fluxo real de pacotes. Se um novo túnel de site estiver sendo planejado ou configurado, comece por Configurar VPN IPsec Site-to-Site no Sophos Firewall. Para fundamentos gerais de CLI, consulte também Resolução de Problemas de CLI no Sophos Firewall: comandos importantes.

Antes da Resolução de Problemas

Primeiro, deve-se documentar brevemente a situação inicial. Isso pode parecer trivial, mas economiza muito tempo, pois muitos problemas de IPsec surgem de suposições assimétricas: um lado acredita que está conectando a rede A à rede B, enquanto o outro lado espera IDs diferentes, sub-redes diferentes ou uma versão IKE diferente.

Pontos importantes:

• Nome do Túnel: azure-vpn
• Gateway Local: Endereço WAN ou FQDN do Sophos Firewall
• Gateway Remoto: IP público ou FQDN do ponto remoto
• Versão IKE: IKEv1 ou IKEv2
• Autenticação: Chave pré-compartilhada ou certificado
• ID Local / ID Remota: Endereço IP, FQDN ou identificador semelhante a e-mail
• Redes Locais: 172.16.10.0/24
• Redes Remotas: 10.20.30.0/24
• Tipo de VPN: baseado em política ou baseado em rota
• Tráfego Esperado: Fonte, Destino, Porta e Direção

Em IPsec baseado em política, as redes locais e remotas fazem parte da negociação do túnel. Em IPsec baseado em rota, é importante saber quais rotas apontam para a interface do túnel. Se o tráfego estiver indo na direção errada apesar do túnel ativo, frequentemente estão envolvidas Rotas IPsec, rotas estáticas, Rotas de Política SD-WAN ou a Precedência de Rota do Sophos Firewall.

Se o túnel estiver ativo e pequenos testes funcionarem, mas transferências maiores travarem, deve-se verificar MTU e MSS. O procedimento está em Verificar MTU e MSS no Sophos Firewall para problemas de VPN.

⚠️ Logs de depuração e capturas de pacotes podem conter dados sensíveis, como endereços IP públicos, redes internas, nomes de host ou dados de usuário. Esses dados devem ser coletados apenas de forma direcionada e por tempo limitado, e revisados antes de serem compartilhados.

Caminho de Diagnóstico

Na prática, uma sequência simples ajuda:

1. O túnel está ativo? Se não, verifique primeiro a versão IKE, perfil IPsec, IDs, PSK/certificado, NAT-T e acessibilidade do ponto remoto.
2. A Fase 2 está estabelecida? Se não, verifique os Seletores de Tráfego, redes locais e remotas, PFS e propostas da Fase 2.
3. Uma Associação de Segurança está instalada? Se sim, verifique ipsec statusall e observe os contadores de bytes.
4. O tráfego está passando pelo túnel? Se não, verifique regras de firewall, NAT, roteamento, precedência de rota, rotas IPsec e caminho de retorno.
5. Os pacotes são visíveis? Se não estiver claro, combine Log Viewer e Captura de Pacotes.

Um erro comum: um status de túnel verde apenas prova que o IPsec foi negociado. Não prova que as regras de firewall estão corretas, que as rotas estão corretas ou que o ponto remoto conhece o caminho de retorno.

Qual Nível Está Afetado?

Antes de analisar logs de depuração, deve-se classificar o problema de forma geral. Isso ajuda a determinar rapidamente se a busca deve ser feita em IKE, Fase 2, roteamento ou fluxo de pacotes.

• Túnel permanece inativo: IKE, Gateway, IDs, PSK, Certificado ou Proposta Verificar strongswan.log ao vivo e comparar Fase 1
• Túnel alterna constantemente entre ativo e inativo: Rekey, DPD, Estabilidade WAN ou Proposta Comparar carimbos de tempo, DPD, tempo de vida e eventos WAN
• Fase 1 está ativa, mas nenhuma Child SA: Seletores de Tráfego, Proposta da Fase 2 ou PFS Verificar redes locais e remotas de forma espelhada
• Túnel está verde, mas contadores de bytes permanecem vazios: Tráfego não atinge o túnel Verificar regra de firewall, NAT, rota e gateway do cliente
• Apenas bytes de saída aumentam: Falta caminho de retorno ou ponto remoto Verificar firewall remoto, rota remota e sistema de destino
• Captura de Pacotes mostra pacotes sem regra correspondente: Ordem de regras, zona ou serviço não correspondem Comparar Log Viewer, Teste de Política e ID da Regra

Essa classificação não substitui uma análise detalhada. No entanto, evita que se procure um erro de Fase 2 nas regras de firewall ou que se redefina desnecessariamente a chave pré-compartilhada em um problema de caminho de retorno.

Coleta de Logs

O Sophos Firewall utiliza StrongSwan para IPsec. Os logs mais importantes estão em /log:

• strongswan.log: principal arquivo de log IPsec para IKE, autenticação e Child SAs
• charon.log: Log do daemon IKE, útil dependendo da versão e situação
• strongswan-monitor.log: Monitoramento do serviço IPsec
• dgd.log: Detecção de Gateway Inativo e Failover de VPN

Acesse o Advanced Shell via SSH e, se necessário, mude para o diretório de logs:

cd /log

O log ao vivo pode ser seguido diretamente:

tail -f /log/strongswan.log

Se vários túneis estiverem ativos, deve-se filtrar. Isso pode ser feito pelo nome do túnel, um IP do par ou um texto de erro típico:

tail -f /log/strongswan.log | grep -i azure-vpn

Para arquivos de log existentes, less é frequentemente mais confortável:

less /log/strongswan.log

No less, pode-se buscar dentro do arquivo com /termo. Alternativamente, grep filtra diretamente:

grep -i "no proposal" /log/strongswan.log

Ativar Debug do StrongSwan

Se o log normal não for suficiente, pode-se colocar o serviço StrongSwan em modo de depuração:

service strongswan:debug -ds nosync

Depois, verifique se o serviço está em modo de depuração:

service -S | grep strongswan

A saída deve mostrar RUNNING,DEBUG para strongswan. Em seguida, reconecte o túnel ou reproduza o erro intencionalmente e observe o log:

tail -f /log/strongswan.log

O mesmo comando de depuração desativa o modo de depuração novamente:

service strongswan:debug -ds nosync

⚠️ Mantenha o debug ativo apenas enquanto for realmente necessário. A depuração de IPsec pode gerar rapidamente grandes arquivos de log e ocupar espaço desnecessário na firewall.

Fase 1: IKE, IDs e Autenticação

Se o túnel não for estabelecido, a causa geralmente está antes ou durante a Fase 1. Nesse ponto, os gateways ainda não negociam redes de dados, mas primeiro IKE, autenticação e as identidades de ambos os lados.

Causas típicas:

• Versão IKE não corresponde
• Perfil IPsec ou proposta não correspondem
• ID local ou remota é diferente do esperado
• Chave pré-compartilhada está incorreta
• Ponto remoto alcança o IP público errado
• NAT-T ou encaminhamento de porta em UDP 500 e 4500 não está correto
• Certificados, CA ou validade não correspondem na autenticação baseada em certificado

No IKE config found

Uma entrada de log como no IKE config found ou NO_PROPOSAL_CHOSEN geralmente significa que o Sophos Firewall não encontra uma configuração IKE adequada para o pacote recebido. Isso pode ser devido à versão IKE, ao gateway, às IDs ou ao perfil IPsec.

Verifique:

• IKEv1 ou IKEv2 está correto em ambos os lados?
• O ponto remoto corresponde ao endereço do Gateway Remoto configurado ou ao FQDN?
• As IDs locais e remotas estão corretas?
• Criptografia, Autenticação, Grupo DH e Tempo de Vida são compatíveis?
• O ponto remoto está usando um IP público diferente do documentado?

Peer authentication failed

peer authentication failed, AUTH_FAILED ou no matching peer config found geralmente indicam IDs ou dados de autenticação incompatíveis. Com chave pré-compartilhada, a chave é frequentemente suspeita primeiro. Isso é muitas vezes correto, mas nem sempre. Se a ID não corresponder, a firewall pode nem verificar a configuração do par esperada.

Verifique:

• A ID Local de um lado corresponde à ID Remota do outro lado.
• A ID Remota de um lado corresponde à ID Local do outro lado.
• Ortografia, maiúsculas e minúsculas, FQDN e endereços IP estão exatamente corretos.
• A chave pré-compartilhada foi inserida sem espaços no início ou no final.
• Com vários túneis para o mesmo ponto remoto, é claro qual conexão deve corresponder.

Invalid HASH_V1 payload ou decryption failed

Em IKEv1, mensagens como invalid HASH_V1 payload length ou decryption failed geralmente indicam uma chave pré-compartilhada incorreta. Em IKEv2, é mais comum ver AUTHENTICATION_FAILED ou AUTH_FAILED.

Na prática, deve-se redefinir a chave pré-compartilhada em ambos os lados, em vez de apenas compará-la visualmente. Copiar e colar de gerenciadores de senhas, espaços invisíveis ou caracteres especiais diferentes são clássicos que consomem tempo.

Fase 2: Seletores de Tráfego e Associações de Segurança

Se a Fase 1 for bem-sucedida, mas a Fase 2 não for estabelecida, geralmente trata-se das redes e da Child SA. O Sophos Firewall deve negociar com o ponto remoto quais sub-redes locais e remotas podem passar pelo túnel.

Indicações típicas de log:

• traffic selectors ... inacceptable
• failed to establish CHILD_SA
• received traffic selectors didn't match
• TSi e TSr mostram redes diferentes do esperado

Verifique:

• Redes locais e remotas estão configuradas de forma espelhada em ambos os lados.
• Máscara de rede e objetos de host individuais estão exatamente corretos.
• Não há sobreposições indesejadas com outros túneis.
• Várias redes da Fase 2 estão representadas de forma idêntica em ambos os lados.
• PFS, Criptografia ESP, Autenticação e Tempo de Vida são compatíveis.

Exemplo: Se o Sophos Firewall espera 172.16.10.0/24 localmente e 10.20.30.0/24 remotamente, o ponto remoto deve oferecer exatamente de forma espelhada 10.20.30.0/24 para 172.16.10.0/24. Um /24 de um lado e um único host ou uma rede maior do outro lado pode ser suficiente para que a Child SA não seja instalada.

Túnel Ativo, mas Sem Tráfego

Se o túnel for exibido como conectado, mas não houver tráfego, o IPsec em si não é automaticamente a causa. Geralmente, trata-se de roteamento, regras de firewall, NAT ou caminho de retorno.

Primeiro, verifique o status do IPsec no Advanced Shell:

ipsec statusall

Os pontos de interesse são principalmente:

• A IKE SA está ESTABLISHED?
• A Child SA está INSTALLED?
• Quais redes locais e remotas são exibidas?
• Os contadores de bytes aumentam em ambas as direções?
• Apenas bytes de saída são visíveis, mas não de entrada?
• Há reconexões ou rekeyings regulares?

Se a Child SA estiver instalada, mas os contadores de bytes permanecerem vazios, o tráfego esperado provavelmente não está atingindo o túnel. Então, verifique o caminho antes e depois do IPsec.

Regras de Firewall

Para que o tráfego passe pelo túnel, são necessárias regras de firewall adequadas. Dependendo do modelo de zonas, isso pode ser LAN para VPN, VPN para LAN ou uma zona própria. A regra deve cobrir corretamente Fonte, Destino, Serviço e Direção.

Importante:

• Ativar Log firewall traffic nas regras relevantes.
• Verificar a posição da regra para garantir que nenhuma regra mais geral seja aplicada antes.
• Escolher corretamente as zonas de Fonte e Destino.
• Não usar objetos muito amplos em vários VPNs, se puderem corresponder ao túnel errado.
• Verificar conscientemente recursos de segurança como IPS, filtro web ou controle de aplicações, se estiverem ativos no tráfego.

Um procedimento geral de verificação é descrito em Testar Regras de Firewall com Log Viewer, Teste de Política e Captura de Pacotes.

Roteamento e Rotas IPsec

Se a firewall não enviar o tráfego para o túnel, verifique as rotas. Em IPsec baseado em política, a tabela de roteamento IPsec pode ser relevante:

ip route show table 220

Se for necessária uma atribuição manual, uma Rota IPsec no Sophos Firewall pode ajudar. Se vários tipos de roteamento competirem, deve-se também verificar a Prioridade de Roteamento do Sophos Firewall.

Verifique:

• Existe uma rota estática mais específica que desvia o tráfego?
• Uma Rota de Política SD-WAN é aplicada antes da rota VPN?
• O gateway do cliente realmente aponta para o Sophos Firewall?
• O ponto remoto tem uma rota de retorno para a rede local?
• Existem redes locais e remotas sobrepostas?

NAT

O NAT não é fundamentalmente errado em IPsec, mas deve ser configurado conscientemente. Um MASQ não intencional ou uma regra SNAT muito ampla pode fazer com que o ponto remoto não associe mais o tráfego à rede esperada.

Verifique:

• Uma regra MASQ genérica é aplicada antes de uma regra VPN-NAT específica?
• O ponto remoto espera endereços IP originais ou traduzidos?
• O NAT está documentado em ambos os lados?
• A regra NAT corresponde à direção do tráfego?

Se o NAT estiver envolvido, o artigo Entender NAT no Sophos Firewall: SNAT, DNAT, MASQ, PAT pode ajudar.

SFOS 22: IPsec baseado em política e NAT devem ser verificados conscientemente

Em atualizações para SFOS 22, o IPsec baseado em política deve ser verificado com cuidado especial. A Sophos menciona nas notas de lançamento do SFOS-22 um comportamento alterado em VPN IPsec baseado em política. Além disso, nos problemas resolvidos, NC-170917 está documentado: O tráfego IPsec baseado em política pode falhar se a regra SNAT padrão estiver configurada com um endereço IP estático em vez de MASQ.

Na prática, isso significa: Se um túnel baseado em política estiver verde após a atualização, mas não houver tráfego ou apenas tráfego unidirecional, o NAT não deve ser tratado como um tema secundário. Uma regra SNAT padrão antiga, ampla ou incomumente ajustada pode alterar exatamente o tráfego que o ponto remoto espera com as redes originais.

Pontos de verificação típicos após uma atualização para SFOS-22:

• O túnel é realmente baseado em política?: Em IPsec baseado em política, as redes locais e remotas fazem parte da negociação. O NAT pode quebrar essa expectativa.
• A regra SNAT padrão foi ajustada?: Um IP SNAT estático em vez de MASQ pode ter efeitos diferentes do esperado após uma atualização.
• Existem regras VPN-NAT específicas?: Elas devem estar acima das regras SNAT ou MASQ gerais e corresponder à direção do tráfego.
• Seletores de Tráfego e objetos NAT correspondem?: O ponto remoto deve esperar as redes originais ou as redes traduzidas, não ambas aleatoriamente.
• A Captura de Pacotes mostra o IP de origem esperado?: Isso revela se a firewall usa um endereço de origem diferente antes do túnel.

Um caso de teste limpo consiste em uma fonte, um destino e um serviço. Em seguida, verifica-se sequencialmente a regra de firewall, regra NAT, ipsec statusall, ip route show table 220, Captura de Pacotes e ponto remoto. Se o teste funcionar apenas com a regra NAT desativada ou movida, o problema não está na configuração do túnel, mas no caminho para o túnel.

Para o planejamento de atualização, consulte também Verificar Sophos Firewall antes da atualização para SFOS 22. Para fundamentos de NAT e ordem de regras, Entender NAT no Sophos Firewall é a melhor introdução.

SFOS 22: PPPoE-WAN com Interface de Alias e Aceleração IPsec

Se após uma atualização para SFOS 22.0 GA ou SFOS 22.0 MR1 um túnel IPsec estiver conectado, mas não encaminhar tráfego, pode haver um caso especial adicional em determinadas configurações. A Sophos lista no Known-Issues NC-181526: Em hardware XGS, túneis IPsec em interfaces de alias de portas PPPoE-WAN podem ser estabelecidos, mas não encaminham tráfego de usuário se a aceleração IPsec estiver ativa.

Este ponto deve ser verificado apenas se as causas normais não se aplicarem. Um túnel verde sem tráfego ainda é geralmente um problema de regra, roteamento, NAT ou caminho de retorno. O caso especial do SFOS-22 torna-se mais provável se todos os seguintes pontos se aplicarem:

• O Sophos Firewall está executando SFOS 22.0 GA ou SFOS 22.0 MR1.
• Trata-se de hardware XGS.
• O túnel afetado usa uma interface de alias em uma porta PPPoE-WAN.
• O túnel é estabelecido, mas o tráfego de usuário não ocorre.
• Regras de firewall, NAT, rotas, caminho de retorno e Captura de Pacotes não explicam o comportamento.
• A aceleração IPsec está ativa.

Como solução alternativa, está documentado desativar a aceleração IPsec:

system ipsec-acceleration off

Isso não deve ser usado como um comando genérico de ajuste de IPsec. A alteração deve ser feita em uma janela de manutenção ou em um procedimento de suporte documentado, com teste antes/depois e clara associação ao problema afetado. A Sophos lista o SFOS 22.0.2 MR2 como a versão de correção para este problema conhecido. Quando essa versão estiver liberada para o ambiente afetado, uma atualização planejada é mais limpa do que uma solução alternativa esquecida permanentemente.

Procedimento prático de verificação:

1. Documentar o status do túnel e ipsec statusall.
2. Executar Captura de Pacotes com filtro de Fonte/Destino restrito.
3. Verificar se o túnel realmente usa uma interface de alias em uma porta PPPoE-WAN.
4. Anotar a versão ativa do SFOS e o modelo de hardware.
5. Testar a alteração na aceleração IPsec apenas de forma direcionada e documentada.
6. Após o teste, comparar contadores de bytes, Captura de Pacotes, Log Viewer e teste de aplicação.

Combinar Log Viewer e Captura de Pacotes

O Log Viewer mostra qual regra ou módulo avaliou uma conexão. Captura de Pacotes no WebAdmin mostra, por outro lado, se os pacotes realmente chegam, são encaminhados, descartados ou processados pela própria firewall.

Para resolução de problemas de IPsec, deve-se definir um teste o mais restrito possível:

• IP de Origem: 172.16.10.25
• IP de Destino: 10.20.30.15
• Serviço: ICMP ou TCP 443
• Direção Esperada: LAN para VPN
• Regra Esperada: LAN_to_VPN_Branch

Depois:

1. Ativar o registro na regra de firewall.
2. Filtrar o Log Viewer com IP de Origem, IP de Destino e módulo Firewall.
3. Iniciar Captura de Pacotes com filtro restrito, por exemplo, host 172.16.10.25 and host 10.20.30.15.
4. Reproduzir o teste exatamente uma vez.
5. Verificar se os pacotes chegam, são encaminhados e se as respostas retornam.

Interpretação:

• Nenhum pacote chega ao Sophos Firewall: Verificar cliente, gateway, VLAN, switch ou roteamento local
• Pacote chega, mas não é encaminhado: Verificar regra de firewall, NAT, rota ou recurso de segurança
• Pacote é enviado para o túnel, mas resposta falta: Verificar rota de retorno, ponto remoto, firewall remoto ou host remoto
• Apenas bytes de saída em ipsec statusall: Verificar caminho de retorno ou política remota
• Apenas bytes de entrada: Verificar rota local, regra de firewall local ou sistema de destino

Para capturas mais longas ou casos de suporte, pode ser útil coletar logs de forma direcionada. O artigo Salvar Logs do Sophos Firewall para Suporte e Análise descreve a exportação limpa.

Erros Típicos

• no IKE config found: Versão IKE, Gateway, IDs ou Perfil não correspondem Comparar versão IKE, ID Local/Remota e Propostas
• NO_PROPOSAL_CHOSEN: Incompatibilidade de Proposta Verificar Criptografia, Autenticação, Grupo DH, PFS e Tempo de Vida
• peer authentication failed: ID ou Autenticação não correspondem Verificar ID Local/Remota e PSK/Certificado
• AUTH_FAILED: Chave pré-compartilhada, Certificado ou ID não correspondem Redefinir PSK, verificar cadeia de certificados e IDs
• traffic selectors ... inacceptable: Redes locais e remotas não correspondem Comparar sub-redes e objetos de host de forma espelhada
• failed to establish CHILD_SA: Redes da Fase 2 ou Propostas ESP não correspondem Verificar Seletores de Tráfego, PFS, Perfil ESP e Tempos de Vida
• Túnel verde, sem bytes: Tráfego não atinge o túnel Verificar regra de firewall, rota, NAT e gateway do cliente
• Bytes de saída, sem entrada: Falta ponto remoto ou caminho de retorno Verificar regras remotas, rota remota e sistema de destino
• Transferências grandes travam apesar do túnel ativo: MTU/MSS, perda de pacotes ou descoberta de MTU de caminho Verificar MTU e MSS para problemas de VPN
• SFOS 22, IPsec baseado em política, túnel verde, falta de tráfego: NAT, SNAT padrão ou Seletores de Tráfego não correspondem após atualização Verificar SNAT padrão, regras VPN-NAT, MASQ, Captura de Pacotes e ponto remoto
• SFOS 22, PPPoE-WAN-Alias, túnel verde, sem tráfego: possível problema conhecido com aceleração IPsec Verificar tipo de interface, versão SFOS e testar system ipsec-acceleration off apenas de forma direcionada
• Reconexões ou rekeys frequentes: Tempo de vida, DPD, linha instável ou problema de proposta Verificar tempos de rekey, DPD, estabilidade WAN e logs

Lista de Verificação Prática

Verifique imediatamente:

• Anotar status do túnel e última mensagem de erro no WebAdmin.
• Iniciar tail -f /log/strongswan.log e reconectar o túnel.
• Verificar versão IKE, ID Local, ID Remota e Chave Pré-compartilhada.
• Comparar Seletores de Tráfego ou redes locais e remotas de forma espelhada.
• Verificar ipsec statusall para ESTABLISHED, INSTALLED e contadores de bytes.

Se o túnel estiver ativo:

• Verificar regras de firewall em ambas as direções.
• Ativar registro nas regras afetadas.
• Filtrar Log Viewer com Fonte, Destino e ID da Regra.
• Executar Captura de Pacotes com filtro restrito.
• Verificar regras NAT e precedência de rota.
• Em SFOS 22 com IPsec baseado em política, verificar SNAT padrão, regras VPN-NAT específicas e IP de origem esperado.
• Em SFOS 22 com PPPoE-WAN-Alias, verificar se o problema conhecido de aceleração IPsec se aplica.
• Confirmar rota de retorno no ponto remoto.

Para suporte ou análise mais longa:

• Ativar debug apenas brevemente e desativar depois.
• Salvar logs relevantes.
• Documentar hora, nome do túnel, IP do par, Fonte, Destino e procedimento de teste.
• Verificar dados sensíveis antes de compartilhar.

FAQ