Melhores Práticas e Troubleshooting em VPN L2L entre ASA e dispositivos Cisco

[Cisco Moderador]

com Thiago Lopes

Bem vindo à discussão na CSC em Português. Esta é sua oportunidade de aprender e fazer todas as perguntas que queira sobre Melhores Práticas e Troubleshooting em VPN L2L entre ASA e dispositivos Cisco

Thiago Lopes faz parte do time de Engenheiros de Suporte na área de segurança para América Latina. Formou-se pelo Centro Federal de Educação Tecnológica Celso Suckow da Fonseca (CEFET/RJ) como Engenheiro Elétrico com ênfase em Eletrônica.   Thiago trabalha na Cisco há 1 ano, possuindo mais de 10 anos de experiência no mercado de Telecomunicações.

Possui as certificações CCNP, CCIP e CCNP security.

Por favor use as estrelas para qualificar  as respostas e assim informar ao especialista que ele já respondeu adequada e satisfatoriamente sua pergunta.

Pode  ser que Thiago não consiga responder a cada uma das perguntas devido à  quantidade que pode vir a receber. Relembramos que se houver qualquer  pergunta que não esteja dentro do tema proposto, por favor a coloque no  fórum adequado à ela.

Este evento estará aberto até o dia 27 de Julho de 2012.

Visite esta discussão frequentemente para conferir as respostas às suas perguntas.

[Christopher Duarte]

Ola Thiago,

Como devo fazer para configurar meu  tráfego de interesse que vai ser transmitido por meu túnel VPN?

Att,

Christopher

[Thiago Lopes]

Ola Christopher, boa tarde!

Vou tentar responder de forma resumida e prática o seu questionamento.

O tráfego de interesse deve ser configurado através de listas de acesso (ACLs). Primeiro devemos identificar qual o fluxo de informações será transmitido pelo túnel VPN (IPs de origem e destino). Depois disto devemos criar a ACL em ambos os dispositivos (de maneira “espelhada”) e aplicar estas ACLs na crypto-map específica do túnel. Favor observar o exemplo abaixo:

A Ponta A possui dois ranges de rede (192.168.1.0/24 e 192.168.2.0/24) que devem comunicar com três redes na Ponta B (172.16.32.0/24, 172.16.33.0/24 e 172.16.34.0/24). As ACLs deverão ser configuradas da seguinte forma:

Ponta A

access-list extended permit ip 192.168.1.0 255.255.255.0 172.16.32.0 255.255.255.0

access-list extended permit ip 192.168.2.0 255.255.255.0 172.16.32.0 255.255.255.0

access-list extended permit ip 192.168.1.0 255.255.255.0 172.16.33.0 255.255.255.0

access-list extended permit ip 192.168.2.0 255.255.255.0 172.16.33.0 255.255.255.0

access-list extended permit ip 192.168.1.0 255.255.255.0 172.16.34.0 255.255.255.0

access-list extended permit ip 192.168.2.0 255.255.255.0 172.16.34.0 255.255.255.0

Ponta B

access-list extended permit ip 172.16.32.0 255.255.255.0 192.168.1.0 255.255.255.0

access-list extended permit ip 172.16.32.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list extended permit ip 172.16.33.0 255.255.255.0 192.168.1.0 255.255.255.0

access-list extended permit ip 172.16.33.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list extended permit ip 172.16.34.0 255.255.255.0 192.168.1.0 255.255.255.0

access-list extended permit ip 172.16.34.0 255.255.255.0 192.168.2.0 255.255.255.0

Após isto, deve-se aplicar a ACL na crypto-map em questão:

crypto map set peer

crypto map match address

Um abraço!

Thiago Lopes

[william.lavieri]

Olá Thiago,

Possuo um extenso ambiente de equipamentos Cisco ASA, entre eles alguns são dedicado para uso de VPN L2L, mas nos ultimos anos tenho me deparado com muitos conflitos de endereçamento entre os Túneis VPN L2L, a saída que encontrei para esse caso foi:

Solicitar aos meus parceiros de negócio que suas configurações de VPN estejam aderentes a RFC 1918, por exemplo, utilizando NAT na sua estrutura interna e dessa maneira a ACL de Trafego Interessante (Crypto-ACL), sempre será concebida com endereços válidos e consequentemente não háverá conflito (overlap) de trafego interessante (crypto-acl).

Mas essa é uma tarefa ardua visto tenho aproximadamente 200 túneis de VPN L2L e só realizei esse ajuste na metade e algunas empresas ainda oferencem resistencia (Ex. TIM Celular - :-( ).

Mas a minha dúvida é justamente sobre o troubleshooting desses casos, já abri alguns TACs na Cisco, mas nunca recebi uma resposta satisfatória. Como faço para evidenciar/comprovar a incidencia de um Overlap de Crypto-ACL???

Visto que analisando a configuração a olho nú (show running-config), a mesma não pode ser identificada, por packet-tracer a mesma coisa e por DEBUG a analise também é subjetiva. Existiria algum comando? Ou road-map para o comando packet-tracer que diga explicitamente "esse túnel A está em conflito com o túnel B"? Ou até uma possível validação do IOS no momento da instalação das configurações?

[Thiago Lopes]

Oi William, boa tarde!

Infelizmente este assunto está mais relacionado com design de rede do que propriamente com uma análise de troubleshooting.

Não  existe uma forma do IOS validar este overlapping, uma vez que as ACLs  podem ser configuradas com diversas finalidades (definição de tráfego de  interesse para uma VPN, restrição de acesso ao equipamento,  service-policy, etc). Você pode configurar duas ACLs com nomes idênticos  e mesma sintaxe e aplicá-las em features distintas.

Além  disto não existe um comando específico para validar isto. A única forma  de identificar um overlapping de crypto ACLs é verificar manualmente as  ACLs configuradas em seu equipamento.

A  melhor maneira de fazer este troubleshooting é analisar o output do  comando  "show crypto ipsec sa peer " para confirmar se o  ipsec flow específico está incrementando os contadores de pkts encrypted  e decrypted. Caso não esteja, podemos utilizar a ferramenta  “packet-tracer” para gerar um pacote dummy e confirmar se o mesmo está  sendo enviado a um túnel VPN ou não. Caso seja de conhecimento prévio a  existencia de overlapping nas crypto ACLs, a mesma deve ser verificada  pelo responsável.

Para resolver este problema podemos utilizar dois workarounds distintos:

• Trocar o range de redes que está dando o overlapping, como já está sendo feito atualmente.
• Aplicar um NAT nas redes em questão.

Um abraço!

Thiago Lopes

[Bruno Rangel]

Olá Thiago

Existe alguma recomendação para trafegar Voz através de VPN?

[Thiago Lopes]

Oi Bruno, bom dia!

Qualquer tráfego que seja "marcado" na ACL de tráfego de interesse deve ser transmitido sem problemas. Não sou um expert em voz para te precisar quais são as limitações e nuâncias de uma transmissão VoIP, mas a maioria dos problemas que vemos com a transmissão de voz por VPNs está relacionada com as inspeções configuradas no firewall (seja de tráfego de voz propriamente dito ou então de tráfego de sinalização).

Através da visualização do output de “show service-policy” você pode verificar se há algum incremento de drops nos protocolos relativos a voz (h323, h225, skinny, sip, etc). Veja o output abaixo:

ASA# sh service-policy

Global policy:

Service-policy: global_policy

   Class-map: inspection_default

     Inspect: dns preset_dns_map, packet 0, drop 0, reset-drop 0

     Inspect: ftp, packet 0, drop 0, reset-drop 0

     Inspect: h323 h225 _default_h323_map, packet 0, drop 0, reset-drop 0

               tcp-proxy: bytes in buffer 0, bytes dropped 0

     Inspect: h323 ras _default_h323_map, packet 0, drop 0, reset-drop 0

     Inspect: rsh, packet 0, drop 0, reset-drop 0

     Inspect: rtsp, packet 0, drop 0, reset-drop 0

               tcp-proxy: bytes in buffer 0, bytes dropped 0

     Inspect: esmtp _default_esmtp_map, packet 0, drop 0, reset-drop 0

     Inspect: sqlnet, packet 0, drop 0, reset-drop 0

     Inspect: skinny , packet 0, drop 0, reset-drop 0

               tcp-proxy: bytes in buffer 0, bytes dropped 0

     Inspect: sunrpc, packet 0, drop 0, reset-drop 0

               tcp-proxy: bytes in buffer 0, bytes dropped 0

     Inspect: xdmcp, packet 0, drop 0, reset-drop 0

     Inspect: sip , packet 0, drop 0, reset-drop 0

               tcp-proxy: bytes in buffer 0, bytes dropped 0

     Inspect: netbios, packet 0, drop 0, reset-drop 0

     Inspect: tftp, packet 0, drop 0, reset-drop 0

     Inspect: ip-options _default_ip_options_map, packet 0, drop 0, reset-drop 0

Dependendo do projeto de voz aplicado não é necessário manter a inspeção do firewall habilitada para esses protocolos.

Um abraço!

Thiago Lopes

[Vitor Salles]

Parabéns pela iniciativa.

Estou com a seguinte dúvida. Dois routers com 1 link cada, trabalhando com GLBP. Abaixo dos routes, dois ASA's, Ativo/Standby. Consigo ter VPN failover nessa topologia?

[Thiago Lopes]

Oi Vitor, boa tarde!

Você pode ter um failover de VPN quando possui dois ASAs configurados em um cenário de alta disponibilidade desde que estejam operando apenas como Ativo/Standby. Não seria possível se os ASAs estivessem configurados como Ativo/Ativo visto que VPN não é suportada em contextos múltiplos.

O failover, neste caso, funcionaria da seguinte forma: os túneis VPN seria estabelecidos no ASA ativo. Caso ocorra um problema com este equipamento um switchover ocorrerá fazendo com o que o ASA standby assuma o papel de ativo e, consequentemente, os tuneis VPN serão estabelecidos com o novo ASA ativo.

Um abraço,

Thiago Lopes.

[Julio Carvalho]

Olá Thiago,

Eu gostaria de saber se é possível usar EIGRP/OSPF em um tunel VPN L2L.

Grato,

Julio

[Thiago Lopes]

Oi Julio, bom dia!

Túneis IPsec no ASA não suportam tráfego multicast. Vale lembrar que os protocolos EIGRP/OSPF utilizam endereços multicast para envio de hellos e para troca de informações de forma a manter a convergência de rede o que impossibilita a utilização destes protocolos através de um túnel IPsec.

A solução é utilizar GRE over IPsec, mas o ASA não suporta esta feature. Neste caso, você teria que utilizar dois roteadores rodando IOS para fazer esta VPN.

Um abraço,

Thiago Lopes