Cisco ASA 5510 - Sonicwall Pro 2040 - funcionamento IPSec a meio

Question

Ok ... Estou tendo um problema IPSec muito estranho (pelo menos estranho para mim :-)). Eu tenho um Sonicwall Pro 2040 conectado a um ASA 5510. Quando o tráfego iniciado a partir do lado Sonicwall da rede, ele funciona bem ... mas se originou do lado ASA, sem dados. Por exemplo, o icmp echo do PC-A na sonicwall é recebido pelo PC-B no ASA. O PC-B responde com uma resposta icmp e o PC-A recebe. Se o PC-B enviar uma solicitação de eco para o PC-A, ele nunca atravessará o túnel IPSec (verificado pela ausência de geração de tráfego ESP através do fio). Um wireshark no PC-B mostra a fonte EXACT SAME IP e MAC no icmp echo request como a resposta do icmp echo ... alguma idéia do que poderia causar esse comportamento? : (

Nota adicional: se eu limpar o isakmp no ASA e tentar fazer ping do PC-B para o PC-A, ele não tentará subir o túnel ... ele não parece perceber que esse tráfego é destinado para a rede sonicwall, mesmo que quando eu enviar respostas de volta funcione bem.

Outra observação: Eu executei uma captura de pacote no ASA usando a mesma ACL exata do túnel IPsec e ela correspondeu aos pacotes de requisição icmp do PC-B ... então, por alguma razão, simplesmente não está tentando enviá-los através do túnel, embora corresponda.

    

Answer 1

Aha ... aparentemente porque eu estava fazendo hairpin na interface interna (testando antes de enviá-la para um site remoto) e a rota padrão estava fora da interface externa, eu precisava colocar uma rota estática lá para encaminhar a Tráfego VPN de volta para a interface interna e, em seguida, ele iria enviá-lo através do túnel. Eu notei isso quando eu estava usando o pacote-tracer e mencionou fluxos ... Eu acho que um fluxo criado por uma entrada de conexão VPN pode ter precedência sobre rotas estáticas ... bom saber: -)