Rota padrão tunneled no Cisco ASA: quando ela realmente se aplica

Um usuário de acesso remoto não alcança nada além do ASA, enquanto o mesmo servidor responde a pings da LAN interna. O túnel sobe, o cliente recebe um endereço do pool, e o pacote ainda sai pela rota padrão da internet ou desaparece. Esse padrão geralmente significa que o tráfego decifrado não encontrou uma rota própria e caiu na rota padrão comum. A correção não é outra regra NAT; é a rota padrão tunneled.

Comece pelo sintoma, não pela configuração

Observe para onde o pacote vai, e não para onde você esperava que ele fosse. Uma captura na interface externa durante uma sessão com falha mostra o pacote decifrado indo para o gateway do ISP com o endereço do pool ainda intacto, ou não mostra nada porque a consulta falhou. De qualquer forma, o túnel não é o problema.

O túnel parece saudável em show vpn-sessiondb, e é exatamente por isso que as pessoas continuam depurando o IKE.

O que separa isso de um descarte de ACL é a direção. Um descarte de ACL é registrado e contado, enquanto uma rota ausente produz uma falha de consulta sem entrada correspondente. Execute show route para o destino do cliente e leia o que o ASA realmente selecionou, incluindo se uma rota padrão foi escolhida e qual.

Como a consulta tunneled difere

O guia da Cisco de roteamento estático no ASA 9.23 documenta uma rota padrão separada para o tráfego VPN decifrado que não tem rota estática ou aprendida. A palavra-chave tunneled marca essa rota, então um pacote decifrado pode cair em um próximo salto diferente do que o ASA usa para o próprio transporte. Rotas mais específicas ainda vencem, e é por isso que um cliente pode alcançar 10.0.0.0/8 pelo gateway interno e perder todo o resto.

Um layout mínimo mantém duas rotas padrão com próximos saltos diferentes. Uma carrega o tráfego do próprio ASA, a outra carrega o tráfego decifrado que não tem rota melhor. Os dois próximos saltos ainda precisam ser alcançáveis a partir da interface à qual você os conecta.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

Se as duas rotas padrão apontam para o mesmo próximo salto, a palavra-chave não muda nada e o sintoma não vai se mover.

As restrições que decidem se funciona

O mesmo guia permite apenas uma rota padrão tunneled e afirma que ECMP não é suportado para ela, então você não pode balancear a carga por esse caminho. Ele também lista restrições envolvendo rastreamento de rotas, verificação de caminho reverso e alguns fluxos de inspeção e gerenciamento. Leia-as em relação à release instalada antes de projetar em torno do recurso. Um projeto que as ignora geralmente falha em um ponto específico em vez de em todos os lugares, e é por isso que o sintoma parece intermitente.

A verificação de caminho reverso é a que morde em projetos assimétricos. Se a resposta chegasse por uma interface diferente da que o ASA espera, o pacote é descartado antes que o roteamento importe. Corrija a topologia ou o caminho de retorno em vez de desativar a verificação para forçar um próximo salto.

O rastreamento de rotas é uma armadilha separada: o objeto rastreado normalmente protege a rota padrão comum, não a tunneled.

O que a palavra-chave não faz

Ela não escolhe o endereço de origem que o ASA usa para construir o IKE. O endpoint externo do túnel segue a seleção de interface e de origem da própria plataforma, e a rota padrão tunneled não participa dessa decisão. Alterá-la não consertará uma phase 1 que sai do endereço errado.

Também não transforma o próximo salto em proxy. Se o destino espera uma troca HTTP CONNECT, enviar pacotes IP brutos a um host proxy só lhe dá um host que não os está roteando. Configure o mecanismo de proxy compatível com o cliente.

E não cria encaminhamento a jusante. O gateway para o qual você aponta ainda precisa de uma rota de volta para o pool VPN, além da tradução de origem onde o projeto exigir.

Verifique o caminho de ponta a ponta

Depois que a rota estiver no lugar, verifique quatro coisas em ordem: show route para um destino de que o pool precisa, uma captura na interface em direção ao novo próximo salto, uma captura no próprio gateway e um caminho de retorno desse gateway até o endereço do pool. As duas primeiras provam que o ASA escolheu o caminho, e as duas últimas provam que alguém responde nele.

Se o gateway responde mas o cliente nunca vê resposta, olhe a tradução de origem e a rota de retorno antes de mexer novamente na tabela de rotas.

Registre a release em que você validou, porque a lista de restrições é específica da versão e um projeto que funciona em um trem pode precisar de outro caminho em outro. Essa nota sobrevive ao trecho de configuração.