Segurança : Dispositivos de segurança adaptáveis Cisco ASA 5500 Series

Soluções de Troubleshooting Mais Comuns de VPN IPsec de Acesso Remoto e L2L

8 Junho 2009 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (28 Abril 2009) | Feedback

Índice

Introdução
Pré-requisitos
      Requisitos
      Componentes Utilizados
      Convenções
Problema - Uma Configuração de VPN IPsec Não Funciona
Soluções
      Habilitação do NAT-Traversal (Problema de VPN de AR #1)
      Teste Adequado da Conectividade
      Habilitação do ISAKMP
      Habilitação/Desabilitação do PFS
      Limpeza de Associações de Segurança Antigas ou Existentes (Túneis)
      Verificação do Tempo de Vida do ISAKMP
      Habilitação ou Desabilitação dos Keepalives de ISAKMP
      Reinserção ou Recuperação de Chaves Pré-Compartilhadas
      Remoção e Reaplicação de Mapas de Criptografia
      Verificação da Presença dos Comandos sysopt (Somente PIX/ASA)
      Verificação da Identidade de ISAKMP
      Verificação do Timeout de Ociosidade/Sessão
      Verificação da Correção das ACLs
      Verificação das Políticas de ISAKMP
      Verificação da Correção do Roteamento
      Verificação da Correção do Conjunto de Transformação
      Verificação dos Números de Seqüência e do Nome do Mapa de Criptografia
      Verificação da Correção do Endereço IP do Peer
      Desabilitação de XAUTH para Peers L2L
Problema - Os Clientes VPN Não Conseguem se Conectar ao ASA/PIX
      Solução
Problema - Os Usuários de Acesso Remoto e da EZVPN se Conectam à VPN e Não Possuem Outro Acesso aos Recursos
Soluções
      Não É Possível Acessar os Servidores na DMZ
      Os Clientes VPN Não Conseguem Resolver DNS
      Separação de Túneis - Não É Possível Acessar a Internet ou Redes Excluídas
      Hairpinning
      Acesso à LAN Local
      Sobreposição de Redes Privadas
Problema - Não É Possível Conectar Mais de Três Usuários de Clientes VPN
Soluções
      Configuração de Logins Simultâneos
      Configuração do ASA/PIX com a CLI
      Configuração do Concentrador
Problema - Não É Possível Iniciar a Sessão ou um Aplicativo e a Transferência Está Lenta Após o Estabelecimento do Túnel
Solução
      Cisco IOS Router
      PIX/ASA 7.X
Problema - Não É Possível Iniciar o Túnel VPN do ASA/PIX
      Solução
Diversos
      Problema
      Problema - WARNING: crypto map entry will be incomplete
Discussões relacionadas da comunidade de suporte da Cisco

Introdução

Este documento contém as soluções mais comuns para problemas de VPN IPsec. Essas soluções foram obtidas diretamente das solicitações de atendimento resolvidas pelo Suporte Técnico da Cisco. Muitas dessas soluções podem ser implementadas antes de um troubleshooting profundo de uma conexão de VPN IPsec. Como resultado, esse documento é apresentado como uma lista de verificação de procedimentos comuns que devem ser tentados antes de você iniciar o troubleshooting de uma conexão e chamar o Suporte Técnico da Cisco.

Se precisar de documentos com exemplos de configuração de VPNs site a site e VPNs de acesso remoto, consulte as seções VPN de Acesso Remoto, VPN Site a Site (L2L) com o PIX, VPN Site a Site (L2L) com o IOS, e VPN Site a Site (L2L) com o VPN3000 de Exemplos de Configuração e Notas Técnicas.

Nota: Mesmo que os exemplos de configuração neste documento sejam para uso em roteadores e em Security Appliances, praticamente todos esses conceitos também se aplicam ao VPN 3000 Concentrator.

Nota: Consulte Troubleshooting de Segurança IP - Entendendo e Utilizando os Comandos de Depuração para obter uma explicação dos comandos de depuração comuns usados no troubleshooting de problemas de IPsec no Cisco IOS® Software e no PIX.

Nota: Você pode procurar qualquer comando usado neste documento com a Command Lookup Tool (somente clientes registrados).

aviso Aviso: Muitas das soluções apresentadas neste documento podem levar à perda temporária de toda a conectividade de VPN IPsec em um dispositivo. Recomenda-se que essas soluções sejam implementadas com cuidado e de acordo com sua política de controle de alterações.

Pré-requisitos

Requisitos

A Cisco recomenda que você adquira conhecimento destes tópicos:

  • Configuração de VPN IPsec em dispositivos Cisco:

    • Cisco PIX 500 Series Security Appliance

    • Cisco ASA 5500 Series Security Appliance

    • Cisco IOS® Routers

    • Cisco VPN 3000 Series Concentrators (Opcional)

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

  • Cisco ASA 5500 Series Security Appliance

  • Cisco PIX 500 Series Security Appliance

  • Cisco IOS

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração padrão. Se a sua rede estiver em um ambiente de produção, esteja ciente do impacto potencial de qualquer comando.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Problema - Uma Configuração de VPN IPsec Não Funciona

Uma solução de VPN IPsec recém configurada ou modificada não funciona.

Uma configuração de VPN IPsec atual não funciona mais.

Soluções

Esta seção contém soluções para os problemas mais comuns de VPN IPsec. Embora elas não sejam relacionadas em uma ordem específica, essas soluções podem ser usadas como uma lista de verificação de itens que devem ser examinados ou experimentados antes de você iniciar um troubleshooting detalhado ou entrar em contato com o TAC. Todas essas soluções são provenientes diretamente de solicitações de serviço do TAC e resolveram inúmeros problemas de clientes.

Nota: Alguns dos comandos nestas seções foram divididos em duas linhas devido a problemas de espaço.

Habilitação do NAT-Traversal (Problema de VPN de AR #1)

O NAT-Traversal, ou NAT-T, permite que o tráfego de VPN atravesse dispositivos de NAT ou PAT, como um roteador Linksys SOHO. Quando o NAT-T não está habilitado, os usuários de clientes VPN freqüentemente parecem se conectar a um PIX ou ASA sem problemas. No entanto, eles não conseguem acessar a rede interna por trás do Security Appliance. Se você não habilitar o NAT-T no dispositivo de NAT/PAT, a mensagem de erro regular translation creation failed for protocol 50 src inside:10.0.1.26 dst outside:10.9.69.4 poderá ser exibida no PIX/ASA.

Nota: No IOS 12.2(13)T ou posterior, o NAT-T é habilitado por padrão no IOS.

O comando a seguir habilita o NAT-T em um Cisco Security Appliance. O 20 no exemplo representa o tempo de keepalive (padrão).

PIX/ASA 7.1 ou anterior

pix(config)#isakmp nat-traversal 20

PIX/ASA 7.2(1) ou posterior

securityappliance(config)#crypto isakmp nat-traversal 20

Os clientes precisam ser modificados também para que tudo funcione.

No Cisco VPN Client, selecione Connection Entries e clique em Modify. Uma nova janela será aberta. Selecione a guia Transport. Nessa guia, selecione Enable Transparent Tunneling e o botão de opção IPSec over UDP (NAT / PAT). Clique em Save e teste a conexão.

Nota: Este comando é o mesmo para o PIX 6.x e o PIX/ASA 7.x.

Nota: É importante permitir a porta 4500 do UDP para NAT-T e as portas 500 do UDP, 1000 do TCP e de ESP com a configuração de uma ACL porque o PIX/ASA funciona como um dispositivo de NAT. Consulte Configurando um Túnel IPsec Através de um Firewall com NAT para obter mais informações sobre a configuração de ACLs em um PIX/ASA.

Concentrador de VPN

Selecione Configuration > Tunneling and Security >IPSEC >NAT Transparency > Enable: IPsec over NAT-T para habilitar o NAT-T no concentrador de VPN.

Nota:  O NAT-T também permite que vários clientes VPN se conectem por meio de um dispositivo de PAT ao mesmo tempo para qualquer headend, seja ele um PIX, roteador ou concentrador.

Teste Adequado da Conectividade

Idealmente, a conectividade de VPN é testada de dispositivos por trás de dispositivos de ponto final que fazem a criptografia, ainda que muitos usuários testem a conectividade de VPN com o comando ping nos dispositivos que fazem a criptografia. Ainda que o ping normalmente funcione para esta finalidade, é importante originá-lo da interface correta. Se a origem do ping estiver incorreta, pode parecer que a conexão de VPN falhou quando na realidade ela funciona. Observe este cenário como um exemplo:

common_ipsec_trouble-1.gif

ACL de criptografia de Router A

access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255

ACL de criptografia de Router B

access-list 110 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255

Nesta situação, um ping deve ser originado da rede "interna" por trás de cada roteador. Isso acontece por que as ACLs de criptografia só estão configuradas para criptografar tráfego com aqueles endereços de origem. Um ping proveniente da interface da Internet de qualquer um dos roteadores não é criptografado. Use as opções estendidas do comando ping no modo EXEC privilegiado para gerar um ping da interface interna de um roteador.

routerA#ping
Protocol [ip]:
Target IP address: 192.168.200.10
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.100.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.200.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.100.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Imagine que os roteadores deste diagrama foram substituídos por PIX ou ASA Security Appliances. O ping usado para testar a conectividade também pode ser gerado da interface interna com a palavra-chave inside:

securityappliance#ping inside 192.168.200.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.200.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Nota: Não é recomendado direcionar seu ping para a interface interna de um Security Appliance. Se for necessário direcionar seu ping para a interface interna, habilite management-access nessa interface. Caso contrário, o dispositivo não responderá.

securityappliance(config)#management-access inside

Habilitação do ISAKMP

Se não houver indicação alguma de que um túnel VPN IPsec foi ativado, é possível que o ISAKMP não tenha sido habilitado. Certifique-se de que o ISAKMP esteja habilitado em seus dispositivos. Use um destes comandos para habilitar o ISAKMP em seus dispositivos:

  • Cisco IOS

    router(config)#crypto isakmp enable
    
  • Cisco PIX 7.1 ou anterior (substitua outside pela interface desejada)

    pix(config)#isakmp enable outside
    
  • Cisco PIX/ASA 7.2(1) ou posterior (substitua outside pela interface desejada)

    securityappliance(config)#crypto isakmp enable outside
    

Habilitação/Desabilitação do PFS

Nas negociações de IPsec, o Perfect Forward Secrecy (PFS) garante que cada nova chave criptográfica não tenha relação com nenhuma chave anterior. Habilite ou desabilite o PFS em ambos os peers do túnel. Caso contrário, o túnel IPsec LAN a LAN (L2L) não será estabelecido no roteador PIX/ASA/IOS.

PIX/ASA:

O PFS é desabilitado por padrão. Para habilitá-lo, use o comando pfs com a palavra-chave enable no modo de configuração de política de grupo. Para desabilitar o PFS, insira a palavra-chave disable.

hostname(config-group-policy)#pfs {enable | disable}

Para remover o atributo de PFS da configuração em execução, insira a forma no deste comando. Uma política de grupo pode herdar um valor para o PFS de outra política de grupo. Insira a forma no deste comando para impedir que um valor seja herdado.

hostname(config-group-policy)#no pfs 

IOS Router:

Para especificar que o IPsec peça o PFS quando novas associações de segurança forem solicitadas para esta entrada do mapa de criptografia, ou que o IPsec exija o PFS ao receber solicitações de novas associações de segurança, use o comando set pfs no modo de configuração do mapa de criptografia. Para especificar que o IPsec não deva solicitar o PFS, use a forma no deste comando. Por padrão, o PFS não é solicitado. Se nenhum grupo for especificado com este comando, group1 será usado como o padrão.

set pfs [group1 | group2]
no set pfs 

Para o comando set pfs:

  • group1 — Especifica que o IPsec deve usar o grupo Diffie-Hellman prime modulus de 768 bits quando o novo intercâmbio Diffie-Hellman é executado.

  • group2 — Especifica que o IPsec deve usar o grupo Diffie-Hellman prime modulus de 1024 bits quando o novo intercâmbio Diffie-Hellman é executado.

Exemplo:

Router(config)#crypto map map 10 ipsec-isakmp
Router(config-crypto-map)#set pfs group2

Limpeza de Associações de Segurança Antigas ou Existentes (Túneis)

Se esta mensagem de erro ocorrer no IOS Router, o problema é que a AS expirou ou foi limpa. O dispositivo final do túnel remoto não sabe que usa um AS expirado para enviar um pacote (não um pacote de estabelecimento de AS). Quando uma nova AS tiver sido estabelecida, a comunicação será retomada. Assim, inicie o tráfego de interesse pelo túnel para criar uma nova AS e restabelecer o túnel.

%CRYPTO-4-IKMP_NO_SA: IKE message from x.x.x.x  has no SA 

Se você limpar as associações de segurança (AS) de ISKAMP (Fase I) e IPsec (Fase II), essa é a solução mais simples, e muitas vezes a melhor solução, para resolver problemas de VPN IPsec.

Ao limpar as ASs, você poderá com freqüência resolver uma grande quantidade de mensagens de erro e comportamentos estranhos sem a necessidade de troubleshooting. Ao mesmo tempo que essa técnica pode ser facilmente usada em qualquer situação, é quase sempre um requisito limpar as ASs após alterar ou adicionar a uma configuração de VPN IPsec atual. Mais ainda, apesar de ser possível limpar somente associações de segurança específicas, os maiores benefícios podem surgir quando você limpa as ASs globalmente no dispositivo.

Nota: Após as associações de segurança serem limpas, talvez seja necessário enviar tráfego pelo túnel para restabelecê-lo.

aviso Aviso: A menos que você especifique quais associações de segurança serão limpas, os comandos relacionados aqui podem limpar todas as associações de segurança no dispositivo. Prossiga com cuidado se houver outros túneis VPN IPsec em uso.

  1. Exiba as associações de segurança antes de limpá-las.

    1. Cisco IOS

      router#show crypto isakmp sa
      router#show crypto ipsec sa
      
    2. Cisco PIX/ASA Security Appliances

      securityappliance#show crypto isakmp sa
      securityappliance#show crypto ipsec sa
      

      Nota: Estes comandos são os mesmos para o Cisco PIX 6.x e o PIX/ASA 7.x

  2. Limpe as associações de segurança. Cada comando pode ser executado conforme mostrado em negrito ou com as opções que os acompanham.

    1. Cisco IOS

      1. ISAKMP (Fase I)

        router#clear crypto isakmp ?
          <0 - 32766>  connection id of SA
          <cr>
      2. IPsec (Fase II)

        router#clear crypto sa ?
          counters  Reset the SA counters
          map       Clear all SAs for a given crypto map
          peer      Clear all SAs for a given crypto peer
          spi       Clear SA by SPI
          <cr>
    2. Cisco PIX/ASA Security Appliances

      1. ISAKMP (Fase I)

        securityappliance#clear crypto isakmp sa
        
      2. IPsec (Fase II)

        security appliance#clear crypto ipsec sa ?
        
          counters  Clear IPsec SA counters
          entry     Clear IPsec SAs by entry
          map       Clear IPsec SAs by map
          peer      Clear IPsec SA by peer
          <cr>

Verificação do Tempo de Vida do ISAKMP

Se os usuários forem freqüentemente desconectados do túnel L2L, o problema pode ser um tempo de vida menor configurado na AS do ISAKMP. Se houver alguma discrepância no tempo de vida do ISAKMP, a mensagem de erro %PIX-5-713092: Group = x.x.x.x, IP = x.x.x.x, Failure during phase 1 rekeying attempt due to collision poderá ser recebida. Configure o mesmo valor em ambos os peers para corrigir o problema.

O padrão é 86.400 segundos (24 horas). Como regra geral, um tempo de vida menor proporciona negociações de ISAKMP mais seguras (até um ponto). No entanto, esses tempos mais curtos permitem que o Security Appliance configure mais rápido ASs futuras de IPsec.

Uma correspondência é feita quando ambas as políticas dos dois peers contêm os mesmos valores de parâmetros de criptografia, hash, autenticação e Diffie-Hellman, e também quando a política do peer remoto especifica um tempo de vida menor ou igual ao tempo de vida especificado na política com a qual a comparação é feita. Se os tempos de vida não forem idênticos, o tempo menor — da política do peer remoto — será usado. Se nenhuma correspondência aceitável for encontrada, o IKE recusará a negociação e a AS de IKE não será estabelecida.

Especifique a vida útil do AS. Este exemplo define uma vida útil de 4 horas (14.400 segundos). O padrão é 86.400 segundos (24 horas).

PIX/ASA

hostname(config)#isakmp policy 2 lifetime  14400

IOS Router

R2(config)#crypto isakmp policy 10
R2(config-isakmp)#lifetime 86400

Habilitação ou Desabilitação dos Keepalives de ISAKMP

Se você configurar os keepalives de ISAKMP, eles ajudarão a impedir o descarte esporádico de VPNs LAN a LAN ou de acesso remoto, o que inclui clientes VPN, túneis e túneis que são descartados após um período de inatividade. Esse recurso permite que o ponto final monitore a presença contínua de um peer remoto e informe a sua própria presença para esse peer. Se o peer parar de enviar respostas, o ponto final removerá a conexão. Para que os keepalives de ISAKMP funcionem, ambos os pontos finais da VPN deverão suportá-los.

  • Configure os keepalives de ISAKMP no IOS com este comando:

    router(config)#crypto isakmp keepalive 15
    
  • Use estes comandos para configurar os keepalives de ISAKMP nos PIX/ASA Security Appliances:

    • Cisco PIX 6.x

      pix(config)#isakmp keepalive 15
      
    • Cisco PIX/ASA 7.x ou posterior para o grupo de túnel chamado 10.165.205.222

      securityappliance(config)#tunnel-group 10.165.205.222
         ipsec-attributes
      
      securityappliance(config-tunnel-ipsec)#isakmp keepalive
         threshold 15 retry 10
      
      

    Em algumas situações, é necessário desabilitar este recurso para resolver o problema, por exemplo, se o cliente VPN estiver por trás de um firewall que impede a passagem de pacotes de DPD.

    Cisco PIX/ASA 7.x ou posterior para o grupo de túnel chamado 10.165.205.222

    Desabilita o processamento de keepalives do IKE, o qual é habilitado por padrão.

    securityappliance(config)#tunnel-group 10.165.205.222
       ipsec-attributes
    
    securityappliance(config-tunnel-ipsec)#isakmp keepalive disable
    

    Desabilite o keepalive para o Cisco VPN Client 4.x

    Selecione %System Root% > Program Files > Cisco Systems > VPN Client > Profiles no PC cliente que está experimentando o problema para desabilitar o keepalive do IKE e edite o PCF file onde aplicável para a conexão.

    Altere 'ForceKeepAlives=0' (padrão) para 'ForceKeepAlives=1'.

Reinserção ou Recuperação de Chaves Pré-Compartilhadas

Em muitos casos, um simples erro de digitação pode ser a causa de um túnel VPN IPsec não ser ativado. Por exemplo, no Security Appliance, as chaves pré-compartilhadas são ocultadas assim que são inseridas. Isso torna impossível verificar se uma chave está incorreta.Certifique-se de ter inserido quaisquer chaves pré-compartilhadas corretamente em cada ponto final de VPN. Insira uma chave novamente para ter certeza de que ela está correta. Essa solução simples pode evitar um troubleshooting mais detalhado.

Em uma VPN de acesso remoto, verifique se um nome de grupo válido e a chave pré-compartilhada correta foram inseridos no Cisco VPN Client. Esse erro poderá ocorrer se o nome do grupo/chave pré-compartilhada não coincidir entre o cliente VPN e o dispositivo headend.

 1 12:41:51.900 02/18/06 Sev=Warning/3 IKE/0xE3000056
 The received HASH payload cannot be verified
 2 12:41:51.900 02/18/06 Sev=Warning/2 IKE/0xE300007D
Hash verification failed
3      14:37:50.562  10/05/06  Sev=Warning/2 IKE/0xE3000099
Failed to authenticate peer (Navigator:904)
4      14:37:50.593  10/05/06  Sev=Warning/2 IKE/0xE30000A5
Unexpected SW error occurred while processing Aggressive Mode
negotiator:(Navigator:2202)
5      14:44:15.937  10/05/06  Sev=Warning/2 IKE/0xA3000067
Received Unexpected InitialContact Notify (PLMgrNotify:888)
6      14:44:36.578  10/05/06  Sev=Warning/3 IKE/0xE3000056
The received HASH payload cannot be verified
7      14:44:36.593  10/05/06  Sev=Warning/2 IKE/0xE300007D
Hash verification failed... may be configured with invalid group password.
8      14:44:36.609  10/05/06  Sev=Warning/2 IKE/0xE3000099
Failed to authenticate peer (Navigator:904)
9      14:44:36.640  10/05/06  Sev=Warning/2 IKE/0xE30000A5
Unexpected SW error occurred while processing Aggressive Mode
negotiator:(Navigator:2202)

Você também pode recuperar uma chave pré-compartilhada sem nenhuma alteração de configuração PIX/ASA Security Appliance. Consulte PIX/ASA 7.x ou posterior: Recuperação da Chave Pré-Compartilhada.

aviso Aviso: Ao remover comandos relacionados à criptografia, provavelmente você desativará um ou todos os seus túneis VPN. Use estes comandos com cuidado e consulte a política de controle de alterações da sua organização antes de executar estes passos.

  • Use estes comandos para remover e inserir novamente a chave pré-compartilhada secretkey para o peer 10.0.0.1 ou o grupo vpngroup no IOS:

    • VPN LAN a LAN Cisco

      router(config)#no crypto isakmp key secretkey
         address 10.0.0.1
      router(config)#crypto isakmp key secretkey
         address 10.0.0.1
      
    • VPN de acesso remoto Cisco

      router(config)#crypto isakmp client configuration
         group vpngroup
      router(config-isakmp-group)#no key secretkey
      router(config-isakmp-group)#key secretkey
      
  • Use estes comandos para remover e inserir novamente a chave pré-compartilhada secretkey para o peer 10.0.0.1 em PIX/ASA Security Appliances:

    • Cisco PIX 6.x

      pix(config)#no isakmp key secretkey address 10.0.0.1
      pix(config)#isakmp key secretkey address 10.0.0.1
      
    • Cisco PIX/ASA 7.x ou posterior

      securityappliance(config)#tunnel-group 10.0.0.1
         ipsec-attributes
      securityappliance(config-tunnel-ipsec)#no pre-shared-key
      securityappliance(config-tunnel-ipsec)#pre-shared-key
         secretkey
      

Remoção e Reaplicação de Mapas de Criptografia

Se você limpar as associações de segurança e isso não resolver um problema de VPN IPsec, remova e reaplique o mapa de criptografia relevante para resolver uma grande variedade de problemas, inclusive o descarte intermitente de túneis VPN.

aviso Aviso: Se você remover um mapa de criptografia de uma interface, os túneis IPsec associados a esse mapa serão desativados com certeza. Siga estes passos com cuidado e considere a política de controle de alterações da sua organização antes de continuar.

  • Use estes comandos para remover e substituir um mapa de criptografia no Cisco IOS:

    Comece pela remoção do mapa de criptografia da interface. Use a forma no do comando crypto map.

    router(config-if)#no crypto map mymap
    

    Continue a usar a forma no para remover um mapa de criptografia inteiro.

    router(config)#no crypto map mymap 10
    

    Substitua o mapa de criptografia na interface Ethernet0/0 para o peer 10.0.0.1. Este exemplo mostra a configuração de mapa de criptografia mínima necessária:

    router(config)#crypto map mymap 10 ipsec-isakmp
    router(config-crypto-map)#match address 101
    router(config-crypto-map)#set transform-set mySET
    router(config-crypto-map)#set peer 10.0.0.1
    router(config-crypto-map)#exit
    router(config)#interface ethernet0/0
    router(config-if)#crypto map mymap
    
  • Use estes comandos para remover e substituir um mapa de criptografia no PIX ou ASA:

    Comece pela remoção do mapa de criptografia da interface. Use a forma no do comando crypto map.

    securityappliance(config)#no crypto map mymap interface outside
    

    Continue a usar a forma no para remover os outros comandos de mapa de criptografia.

    securityappliance(config)#no crypto map mymap 10 match
       address 101
    securityappliance(config)#no crypto map mymap set
       transform-set mySET
    securityappliance(config)#no crypto map mymap set
       peer 10.0.0.1
    

    Substitua o mapa de criptografia para o peer 10.0.0.1. Este exemplo mostra a configuração de mapa de criptografia mínima necessária:

    securityappliance(config)#crypto map mymap 10 ipsec-isakmp
    securityappliance(config)#crypto map mymap 10
       match address 101
    securityappliance(config)#crypto map mymap 10 set
       transform-set mySET
    securityappliance(config)#crypto map mymap 10 set
       peer 10.0.0.1
    securityappliance(config)#crypto map mymap interface outside
    

Nota: Se você remover e reaplicar o mapa de criptografia, o problema de conectividade também será resolvido caso o endereço IP do headend e tenha sido alterado.

Verificação da Presença dos Comandos sysopt (Somente PIX/ASA)

Os comandos sysopt connection permit-ipsec e sysopt connection permit-vpn permitem que os pacotes de um túnel IPsec e suas payloads desviem das ACLs da interface no Security Appliance. Os túneis IPsec terminados no Security Appliance provavelmente falharão se um destes comandos não for habilitado.

No Security Appliance Software Versão 7.0 ou anterior, o comando sysopt relevante para esta situação é sysopt connection permit-ipsec.

No Security Appliance Software Versão 7.1(1) ou posterior, o comando sysopt relevante para esta situação é sysopt connection permit-vpn.

No PIX 6.x, esta funcionalidade é desabilitada por padrão. No PIX/ASA 7.0(1) ou posterior, a funcionalidade é habilitada por padrão. Use estes comandos show para determinar se o comando sysopt relevante está habilitado em seu dispositivo:

  1. Cisco PIX 6.x

    pix# show sysopt
    no sysopt connection timewait
    sysopt connection tcpmss 1380
    sysopt connection tcpmss minimum 0
    no sysopt nodnsalias inbound
    no sysopt nodnsalias outbound
    no sysopt radius ignore-secret
    no sysopt uauth allow-http-cache
    no sysopt connection permit-ipsec
    
    !--- sysopt connection permit-ipsec está desabilitado
    
    no sysopt connection permit-pptp
    no sysopt connection permit-l2tp
    no sysopt ipsec pl-compatible
    
  2. Cisco PIX/ASA 7.x

    securityappliance# show running-config sysopt
    no sysopt connection timewait
    sysopt connection tcpmss 1380
    sysopt connection tcpmss minimum 0
    no sysopt nodnsalias inbound
    no sysopt nodnsalias outbound
    no sysopt radius ignore-secret
    sysopt connection permit-vpn
    
    !--- sysopt connection permit-vpn está habilitado
    !--- Este dispositivo está executando 7.2(2)
    
    

Use estes comandos para habilitar o comando sysopt correto para seu dispositivo:

  • Cisco PIX 6.x e PIX/ASA 7.0

    pix(config)#sysopt connection permit-ipsec
    
  • Cisco PIX/ASA 7.1(1) ou posterior

    securityappliance(config)#sysopt connection permit-vpn
    

Nota: Se não desejar usar o comando sysopt connection, você deverá permitir explicitamente o tráfego necessário, o qual é o tráfego de interesse da origem para o destino, por exemplo, da LAN do dispositivo remoto para a LAN do dispositivo local e da "porta 500 do UDP" da interface externa do dispositivo remoto para a interface externa do dispositivo local, na ACL externa.

Verificação da Identidade de ISAKMP

Se o túnel VPN IPsec falhou na negociação de IKE, isso pode ter ocorrido devido à incapacidade do PIX ou de seu peer reconhecer a identidade do seu peer. Quando dois peers usam o IKE para estabelecer associações de segurança de IPsec, cada peer envia sua identidade de ISAKMP para o peer remoto. Ele envia seu endereço IP ou nome de host dependendo de como a identidade de ISAKMP de cada um foi definida. Por padrão, a identidade de ISAKMP da unidade PIX Firewall é definida como o endereço IP. Como regra geral, defina o Security Appliance e as identidades de seus peers da mesma forma para evitar uma falha de negociação de IKE.

Para fazer com que o ID da Fase 2 seja enviado para o peer, use o comando isakmp identity no modo de configuração global.

crypto isakmp identity address

!--- Se os túneis VPN de acesso remoto ou L2L (site a site) se conectarem
!--- com chave pré-compartilhada como o tipo de autenticação

OU

crypto isakmp identity auto

!--- Se os túneis VPN de acesso remoto ou L2L (site a site) se conectarem
!--- com negociação de ISAKMP por tipo de conexão; endereço IP para
!--- chave pré-compartilhada ou DN cert para autenticação de certificado.

OU

crypto isakmp identity hostname

!--- Usa o nome de domínio totalmente qualificado do
!--- host que troca informações de identidade de ISAKMP (padrão).
!--- Este nome compreende o nome de host e o nome do domínio.

Nota: O comando isakmp identity foram substituídos no software versão 7.2(1). Consulte a Referência de Comandos do Cisco Security Appliance Versão 7.2 para obter mais informações.

Verificação do Timeout de Ociosidade/Sessão

Se o timeout de ociosidade for definido como 30 minutos (padrão), o túnel será descartado após 30 minutos sem que tráfego passe por ele. O cliente VPN será desconectado após 30 minutos, independentemente da configuração do timeout de ociosidade e receberá o erro PEER_DELETE-IKE_DELETE_UNSPECIFIED.

Configure idle timeout e session timeout como none para fazer com que o túnel esteja sempre ativo e nunca seja descartado.

PIX/ASA 7.x ou posterior

Insira o comando vpn-idle-timeout no modo de configuração de política de grupo ou no modo de configuração de nome de usuário para configurar o período de timeout do usuário.

hostname(config)#group-policy DfltGrpPolicy attributes
hostname(config-group-policy)#vpn-idle-timeout none

Configure o tempo máximo para as conexões de VPN com o comando vpn-session-timeout no modo de configuração de política de grupo ou no modo de configuração de nome de usuário:

hostname(config)#group-policy DfltGrpPolicy attributes
hostname(config-group-policy)#vpn-session-timeout none

Cisco IOS Router

Use o comando crypto ipsec security-association idle-time no modo de configuração global ou no modo de configuração do mapa de criptografia para configurar o temporizador de ociosidade da AS IPsec. Por padrão, esses temporizadores estão desabilitados.

crypto ipsec security-association idle-time 
seconds 

O tempo é expresso em seconds, e representa o período no qual o temporizador de ociosidade permite que um peer inativo mantenha uma AS. Os valores válidos para o argumento seconds variam entre 60 e 86.400.

Verificação da Correção das ACLs

Há duas listas de acesso usadas em uma configuração de VPN IPsec típica. Uma lista de acesso é usada para excluir tráfego destinado ao túnel de VPN do processo de NAT. A outra lista de acesso define o tráfego que será criptografado. Isso inclui uma ACL de criptografia em uma configuração LAN a LAN ou uma ACL de separação de túneis em uma configuração de acesso remoto. Quando essas ACLs estão configuradas incorretamente ou ausentes, o tráfego pode fluir em apenas uma direção ao longo do túnel ou não ser enviado de forma alguma.

Certifique-se de ter configurado todas as listas de acesso necessárias para concluir sua configuração de VPN IPsec e de que essas listas de acesso definem o tráfego correto. Esta lista contém aspectos simples a serem verificados quando você suspeitar que uma ACL é a causa dos problemas com sua VPN IPsec.

  • Certifique-se de que sua exceção de NAT e as ACLs de criptografia especifiquem o tráfego correto.

  • Se houver vários túneis VPN e várias ACLs de criptografia, certifique-se de que essas ACLs não interfiram umas nas outras.

  • Não use ACLs duas vezes. Mesmo que sua ACL de exceção de NAT e a ACL de criptografia especifiquem o mesmo tráfego, use duas listas de acesso diferentes.

  • Na configuração de acesso remoto, não use lista de acesso para o tráfego de interesse com o mapa de criptografia dinâmica. Isso poderá fazer com que o cliente VPN seja incapaz de se conectar ao dispositivo headend. Se você configurou por engano a ACL de criptografia para a VPN de acesso remoto, a mensagem de erro %ASA-3-713042: IKE Initiator unable to find policy: Intf 2 poderá ser exibida.

    Consulte Exemplo de Configuração do PIX/ASA 7.x e do Cisco VPN Client 4.x com Autenticação IAS RADIUS (contra Active Directory) do Windows 2003 para obter um exemplo de configuração que mostra como estabelecer a conexão de VPN de acesso remoto entre um Cisco VPN Client e o PIX/ASA.

  • Certifique-se de que seu dispositivo esteja configurado para usar a ACL de exceção de NAT. Em um roteador, isso significa que você usa o comando route-map. No PIX ou ASA, significa que você usa o comando nat (0). Uma ACL de exceção de NAT é necessária para as configurações de LAN a LAN e de acesso remoto.

    • Aqui um IOS Router é configurado para excluir o tráfego enviado entre 192.168.100.0 /24 e 192.168.200.0 /24 ou 192.168.1.0 /24 do NAT. O tráfego destinado a qualquer outro lugar é sujeito à sobrecarga de NAT:

      access-list 110 deny ip 192.168.100.0 0.0.0.255
         192.168.200.0 0.0.0.255
      access-list 110 deny ip 192.168.100.0 0.0.0.255
         192.168.1.0 0.0.0.255
      access-list 110 permit ip 192.168.100.0 0.0.0.255 any
      
      route-map nonat permit 10
        match ip address 110
      
      ip nat inside source route-map nonat interface FastEthernet0/0 overload
    • Aqui um PIX é configurado para excluir o tráfego enviado entre 192.168.100.0 /24 e 192.168.200.0 /24 ou 192.168.1.0 /24 do NAT. Por exemplo, todo o restante do tráfego é sujeito à sobrecarga de NAT:

      access-list noNAT extended permit ip 192.168.100.0
         255.255.255.0 192.168.200.0 255.255.255.0
      access-list noNAT extended permit ip 192.168.100.0
         255.255.255.0 192.168.1.0 255.255.255.0
      
      nat (inside) 0 access-list noNAT
      nat (inside) 1 0.0.0.0 0.0.0.0
      
      global (outside) 1 interface

      Nota: As ACLs de exceção de NAT funcionam somente com o endereço IP ou redes IP, como nos exemplos mencionados (lista de acesso noNAT) e devem ser idênticas às ACLs de mapa de criptografia. As ACLs de exceção de NAT não funcionam com os números de porta (por exemplo, 23, 25, etc.).

      Nota:  Exemplo incorreto:

      access-list noNAT extended permit ip 192.168.100.0
         255.255.255.0 192.168.200.0 255.255.255.0 eq 25
      
  • Certifique-se de que suas ACLs não estejam invertidas e sejam do tipo correto.

    • As ACLs de exceção de NAT e criptografia para configurações de LAN a LAN devem ser escritas da perspectiva do dispositivo na qual a ACL está configurada. Isso significa que cada ACLs deve espelhar a outra. Neste exemplo, um túnel LAN a LAN é estabelecido entre 192.168.100.0 /24 e 192.168.200.0 /24.

      common_ipsec_trouble-1.gif

      ACL de criptografia de Router A

      access-list 110 permit ip 192.168.100.0 0.0.0.255
         192.168.200.0 0.0.0.255

      ACL de criptografia de Router B

      access-list 110 permit ip 192.168.200.0 0.0.0.255
         192.168.100.0 0.0.0.255

      Nota: Embora não seja ilustrado aqui, o mesmo conceito se aplica aos PIX e ASA Security Appliances.

    • As ACLs de separação de túneis para as configurações de acesso remoto devem ser listas de acesso padrão que permitem o tráfego para a rede à qual os clientes VPN precisam obter acesso.

      Nota: Na lista de acesso estendida, usar 'any' na origem na ACL de separação de túneis é semelhante a desabilitar a separação. Use somente as redes de origem na ACL estendida para a separação de túneis.

      Nota:  Exemplo correto:

      access-list 140 permit ip 10.1.0.0 0.0.255.255 10.18.0.0 0.0.255.255

      Nota:  Exemplo incorreto:

      access-list 140 permit ip any 10.18.0.0 0.0.255.255

      common_ipsec_trouble-2.gif

      • Cisco IOS

        router(config)#access-list 10 permit ip 192.168.100.0
        router(config)#crypto isakmp client configuration group MYGROUP
        router(config-isakmp-group)#acl 10
        
      • Cisco PIX 6.x

        pix(config)#access-list 10 permit 192.168.100.0
           255.255.255.0
        pix(config)#vpngroup MYGROUP split-tunnel 10
        
      • Cisco PIX/ASA 7.x

        securityappliance(config)#access-list 10 standard
           permit 192.168.100.0 255.255.255.0
        securityappliance(config)#group-policy MYPOLICY internal
        securityappliance(config)#group-policy MYPOLICY attributes
        securityappliance(config-group-policy)#split-tunnel-policy
           tunnelspecified
        securityappliance(config-group-policy)#split-tunnel-network-list
           value 10
        

Verificação das Políticas de ISAKMP

Se o túnel IPsec não estiver ativado, verifique se as políticas de ISAKMP correspondem às dos peers remotos. Esta política de ISAKMP é aplicável à VPN site a site (L2L) e à VPN de acesso remoto.

Se os Cisco VPN Clients ou a VPN Site a Site não forem capazes de estabelecer o túnel com o dispositivo remoto, verifique se os dois peers contêm os mesmos valores de parâmetros de criptografia, hash, autenticação e Diffie-Hellman e quando a política do ponto remoto especifica um tempo de vida menor ou igual ao tempo de vida na política enviada pelo iniciador. Se os tempos de vida não forem idênticos, o Security Appliance usará o menor. Se não houver uma correspondência aceitável, o ISAKMP recusará a negociação e a AS não será estabelecida.

Se o Cisco VPN Client não conseguir se conectar ao dispositivo headend, o problema pode ser a diferença na política de ISAKMP. O dispositivo headend deve corresponder a uma das propostas de IKE do Cisco VPN Client.

Nota: Para a política de ISAKMP e o conjunto de transformação de IPsec usados no PIX/ASA, o Cisco VPN Client não pode usar uma diretiva com uma combinação de DES e SHA. Se você usa o DES, é necessário usar MD5 como o algoritmo de hash ou então as outras combinações, 3DES com SHA e 3DES com MD5.

Verificação da Correção do Roteamento

O roteamento é uma parte crítica de quase todas as implementações de VPN IPsec. Certifique-se de que seus dispositivos de criptografia como roteadores e PIX ou ASA Security Appliances possuam as informações de roteamento apropriadas para enviar tráfego pelo seu túnel VPN. Mais ainda, se houver outros roteadores por trás do seu dispositivo de gateway, verifique se esses roteadores sabem como acessar o túnel e também quais redes estão do outro lado.

Um componente chave do roteamento em uma implementação de VPN é a Injeção de Rota Reversa (RRI). A RRI insere entradas dinâmicas para redes remotas ou clientes VPN na tabela de roteamento de um gateway de VPN. Essas rotas são úteis para o dispositivo em que elas estão instaladas, bem como para outros dispositivos na rede porque as rotas instaladas pela RRI podem ser redistribuídas por meio de um protocolo de roteamento como o EIGRP ou o OSPF.

  • Em uma configuração LAN a LAN, é importante de cada ponto de extremidade possua uma ou mais rotas para as redes para as quais deve criptografar o tráfego. Neste exemplo, Router A deve ter rotas para as redes por trás de Router B através de 10.89.129.2. Router B deve ter uma rota semelhante para 192.168.100.0 /24:

    common_ipsec_trouble-3.gif

    • A primeira forma de garantir que cada roteador conheça as rotas apropriadas é configurar rotas estáticas para cada rede de destino. Por exemplo, Router A pode ter estas instruções de rota configuradas:

      ip route 0.0.0.0 0.0.0.0 172.22.1.1
      ip route 192.168.200.0 255.255.255.0 10.89.129.2
      ip route 192.168.210.0 255.255.255.0 10.89.129.2
      ip route 192.168.220.0 255.255.255.0 10.89.129.2
      ip route 192.168.230.0 255.255.255.0 10.89.129.2

      Se Router A foi substituído por um PIX ou ASA, a configuração pode ser semelhante a:

      route outside 0.0.0.0 0.0.0.0 172.22.1.1
      route outside 192.168.200.0 255.255.255.0 10.89.129.2
      route outside 192.168.200.0 255.255.255.0 10.89.129.2
      route outside 192.168.200.0 255.255.255.0 10.89.129.2
      route outside 192.168.200.0 255.255.255.0 10.89.129.2
    • Se houver uma grande quantidade de redes por trás de cada ponto final, a configuração das rotas estáticas se torna difícil de administrar. Em vez disso, recomenda-se usar a Injeção de Rota Reversa, conforme mostrado. A RRI coloca nas tabelas de roteamento rotas para todas as redes remotas listadas na ACL de criptografia. Por exemplo, a ACL de criptografia e o mapa de criptografia de Router A podem ser semelhantes a:

      access-list 110 permit ip 192.168.100.0 0.0.0.255
         192.168.200.0 0.0.0.255
      access-list 110 permit ip 192.168.100.0 0.0.0.255
         192.168.210.0 0.0.0.255
      access-list 110 permit ip 192.168.100.0 0.0.0.255
         192.168.220.0 0.0.0.255
      access-list 110 permit ip 192.168.100.0 0.0.0.255
         192.168.230.0 0.0.0.255
      
      crypto map myMAP 10 ipsec-isakmp
       set peer 10.89.129.2
       reverse-route
       set transform-set mySET
       match address 110

      Se Router A foi substituído por um PIX ou ASA, a configuração pode ser semelhante a:

      access-list cryptoACL extended permit ip 192.168.100.0
         255.255.255.0 192.168.200.0 255.255.255.0
      access-list cryptoACL extended permit ip 192.168.100.0
         255.255.255.0 192.168.210.0 255.255.255.0
      access-list cryptoACL extended permit ip 192.168.100.0
         255.255.255.0 192.168.220.0 255.255.255.0
      access-list cryptoACL extended permit ip 192.168.100.0
         255.255.255.0 192.168.230.0 255.255.255.0
      
      crypto map myMAP 10 match address cryptoACL
      crypto map myMAP 10 set peer 10.89.129.2
      crypto map myMAP 10 set transform-set mySET
      crypto map mymap 10 set reverse-route
      
  • Em uma configuração de acesso remoto, alterações de rotas nem sempre são necessárias. Se houver outros roteadores por trás do roteador gateway ou Security Appliance da VPN, esses roteadores precisam aprender o caminho para os clientes VPN de alguma forma. Neste exemplo, suponha que os clientes VPN recebam endereços no intervalo 10.0.0.0 /24 ao se conectarem.

    common_ipsec_trouble-4.gif

    Se não houver protocolo de roteamento em uso pelo gateway e os outros roteadores, rotas estáticas poderão ser usadas em roteadores como Router 2:

    ip route 10.0.0.0 255.255.255.0 192.168.100.1

    Se um protocolo de roteamento como o EIGRP ou OSPF for usado entre o gateway e os outros roteadores, recomenda-se usar a Injeção de Rota Reversa da forma descrita. A RRI adiciona automaticamente as rotas para o cliente VPN à tabela de roteamento do gateway. Essas rotas podem então ser distribuídas para os outros roteadores da rede.

    • Cisco IOS Router:

      crypto dynamic-map dynMAP 10
       set transform-set mySET
       reverse-route
      
      crypto map myMAP 60000 ipsec-isakmp dynamic dynMAP
    • Cisco PIX ou ASA Security Appliance:

      crypto dynamic-map dynMAP 10 set transform-set mySET
      crypto dynamic-map dynMAP 10 set reverse-route
      
      crypto map myMAP 60000 ipsec-isakmp dynamic dynMAP

Nota: O problema de roteamento ocorre quando o pool de endereços IP atribuídos aos clientes VPN se sobrepõe às redes internas do dispositivo headend. Para obter informações adicionais, consulte a seção Sobreposição de Redes Privadas.

Verificação da Correção do Conjunto de Transformação

Verifique se a criptografia de IPsec e os algoritmos de hash a serem usados pelo conjunto de transformação em ambos os pontos finais são os mesmos. Consulte a seção Referência de Comandos do Guia de Configuração do Cisco Security Appliance para obter mais informações.

Nota: Para a política de ISAKMP e o conjunto de transformação de IPsec usados no PIX/ASA, o Cisco VPN Client não pode usar uma diretiva com uma combinação de DES e SHA. Se você usa o DES, é necessário usar MD5 como o algoritmo de hash ou então as outras combinações, 3DES com SHA e 3DES com MD5.

Verificação dos Números de Seqüência e do Nome do Mapa de Criptografia

Se houver peers estáticos e dinâmicos configurados no mesmo mapa de criptografia, a ordem das entradas do mapa será muito importante. O número de seqüência da entrada dinâmica do mapa de criptografia deverá ser mais alto que o de todas as outras entradas estáticas desse mapa. Se as entradas estáticas tiverem uma numeração superior à da entrada dinâmica, as conexões com esses peers falharão e depurações como as mostradas aqui serão exibidas.

IKEv1]: Group = x.x.x.x, IP = x.x.x.x, QM FSM error (P2 struct &0x49ba5a0, mess id 0xcd600011)!
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Removing peer from correlator table failed, no match!

Nota: Somente um mapa de criptografia dinâmica é permitido para cada interface no Security Appliance.

Este é um exemplo de um mapa de criptografia numerado corretamente que contém uma entrada estática e outra dinâmica. Observe que a entrada dinâmica tem o número de seqüência mais alto e há espaço para entradas estáticas adicionais:

crypto dynamic-map cisco 20 set transform-set myset
crypto map mymap 10 match address 100
crypto map mymap 10 set peer 172.16.77.10
crypto map mymap 10 set transform-set myset
crypto map mymap interface outside
crypto map mymap 60000 ipsec-isakmp dynamic cisco

Nota: Os nomes de mapas de criptografia diferenciam maiúsculas de minúsculas.

Nota: Verifique se o mapa de criptografia é aplicado na interface certa na qual o túnel IPsec é iniciado/terminado.

Nos cenários em que vários túneis VPN são terminados na mesma interface, precisamos criar um mapa de criptografia com o mesmo nome (somente um mapa de criptografia é permitido por interface), mas com um número de seqüência diferente. Isso é verdadeiro para o roteador, PIX e ASA.

Consulte Configurando o IPsec Entre PIXs Hub e Remotos com Clientes VPN e Autenticação Estendida para obter mais informações sobre a configuração de um PIX hub para o mesmo mapa de criptografia com números de seqüência diferentes na mesma interface. Da mesma forma, consulte PIX/ASA 7.X: Adicionar um Novo Túnel ou Acesso Remoto a Uma VPN L2L Existente para obter mais informações sobre a configuração do mapa de criptografia para os cenários de VPN L2L e de acesso remoto.

Verificação da Correção do Endereço IP do Peer

Para uma configuração de VPN LAN a LAN (L2L) de um PIX/ASA Security Appliance 7.x, você deve especificar o <name> do grupo do túnel e o Remote peer IP Address (extremidade remota do túnel) no comando tunnel-group <name> type ipsec-l2l para a criação e o gerenciamento do banco de dados de registros específicos de conexão do IPsec. O endereço IP do peer deve coincidir nos comandos tunnel group name e Crypto map set address. Quando você configura a VPN com o ASDM, o número do grupo do túnel é gerado automaticamente com o endereço IP do peer correto.

Para uma configuração de VPN LAN a LAN (L2L) de um PIX 6.x, o endereço IP do peer (extremidade remota do túnel) deve coincidir com os comandos isakmp key address e set peer no mapa de criptografia para uma conexão de VPN IPsec bem sucedida.

Desabilitação de XAUTH para Peers L2L

Se um túnel LAN a LAN e um túnel de acesso remoto estiverem configurados no mesmo mapa de criptografia, informações de XAUTH serão solicitadas ao peer LAN a LAN e o túnel L2L falhará.

Nota: Este problema se aplica somente ao Cisco IOS e ao PIX 6.x. O PIX/ASA 7.x não é afetado porque usa grupos de túneis.

Use a palavra-chave no-xauth ao inserir a chave isakmp para que o dispositivo não solicite ao peer as informações de XAUTH (nome de usuário e senha). Esta palavra-chave desabilita o XAUTH para peers IPsec estáticos. Insira uma comando semelhante a este no dispositivo que possui tanto a VPN L2L quanto a de acesso remoto configuradas no mesmo mapa de criptografia:

router(config)# crypto isakmp key cisco123 address
   172.22.1.164 no-xauth

No cenário em que o PIX/ASA 7.x atua como o Easy VPN Server, o Easy VPN Client não é capaz de se conectar ao headend devido a um problema de Xauth. Desabilite a autenticação de usuários no PIX/ASA para resolver o problema conforme mostrado:

ASA(config)#tunnel-group example-group type ipsec-ra
ASA(config)#tunnel-group example-group ipsec-attributes
ASA(config-tunnel-ipsec)#isakmp ikev1-user-authentication none

Consulte a seção Diversos deste documento para saber mais sobre o comando isakmp ikev1-user-authentication.

Problema - Os Clientes VPN Não Conseguem se Conectar ao ASA/PIX

Os Cisco VPN Clients não conseguem autenticar quando o xauth é usado com o servidor Radius.

Solução

O problema pode ser o timeout do xauth. Aumente o valor do timeout do servidor AAA para resolver o problema.

Por exemplo:

Hostname(config)#aaa-server test protocol radius
hostname(config-aaa-server-group)#aaa-server test host 10.2.3.4
hostname(config-aaa-server-host)#timeout 10

Problema - Os Usuários de Acesso Remoto e da EZVPN se Conectam à VPN e Não Possuem Outro Acesso aos Recursos

Os usuários de acesso remoto não têm conectividade com a Internet após se conectarem à VPN.

Os usuários de acesso remoto não podem acessar recursos localizados por trás de outras VPNs no mesmo dispositivo.

Os usuários de acesso remoto podem acessar somente a rede local.

Soluções

Não É Possível Acessar os Servidores na DMZ

Após o cliente VPN estabelecer o túnel IPsec com o dispositivo headend da VPN (PIX/ASA/IOS Router), os usuários do cliente VPN são capazes de acessar os recursos da rede INSIDE (10.10.10.0/24), mas não conseguem acessar a rede DMZ (10.1.1.0/24). .

Diagrama 1:

common_ipsec_trouble-8.gif

Verifique se a configuração NO NAT de separação de túneis foi adicionada ao dispositivo headend para permitir o acesso aos recursos da rede DMZ.

Exemplo 1:

ASA/PIX

ciscoasa#show running-config


!--- Separação de túnel para o acesso àrede interna

access-list vpnusers_spitTunnelAcl permit ip 10.10.10.0 255.255.0.0 any


!--- Separação de túnel para o acesso à rede DMZ

access-list vpnusers_spitTunnelAcl permit ip 10.1.1.0 255.255.0.0 any


!--- Crie um pool de endereços do qual os endereços IP são atribuídos
!--- dinamicamente para os clientes VPN remotos.

ip local pool vpnclient 192.168.1.1-192.168.1.5


!--- Esta lista de acesso é usada para um comando nat zero que impede
!--- que o tráfego correspondente à lista de acesso passe pelo processo de NAT.

!--- Sem NAT para a rede DMZ. 


access-list nonat-dmz permit ip  10.1.1.0 255.255.255.0  192.168.1.0 255.255.255.0


!--- Sem NAT para a rede interna.

access-list nonat-in permit ip  10.10.10.0 255.255.255.0  192.168.1.0 255.255.255.0


!--- NAT 0 impede a aplicação do NAT para as redes especificadas na ACL nonat

.
nat (DMZ) 0 access-list nonat-dmz
nat (inside) 0 access-list nonat-in 

Após você adicionar uma nova entrada para a configuração de NAT, limpe a conversão de NAT.

Clear xlate
Clear local

Verifique:

Se o túnel tiver sido estabelecido, vá para o Cisco VPN Client e selecione Status > Route Details para verificar se as rotas seguras são mostradas para as redes DMZ e INSIDE.

common_ipsec_trouble-9.gif

Consulte PIX/ASA 7.x: Exemplo de Configuração de Acesso a Servidor de E-Mail na DMZ para obter mais informações de como configurar o PIX Firewall para permitir o acesso a um servidor de e-mail localizado na zona desmilitarizada (rede DMZ).

Consulte PIX/ASA 7.x: Adicionar um Novo Túnel ou Acesso Remoto a Uma VPN L2L Existente para ver os passos necessários para adicionar um novo túnel VPN ou uma VPN de acesso remoto a uma configuração de VPN L2L existente.

Consulte PIX/ASA 7.x: Exemplo de Configuração de Permissão de Separação de Túneis para Clientes VPN no ASA para obter instruções passo a passo de como permitir que os clientes VPN acessem a Internet enquanto estão encapsulados em um Cisco Adaptive Security Appliance (ASA) 5500 Series Security Appliance.

Consulte Exemplo de Configuração do PIX/ASA 7.x e do Cisco VPN Client 4.x com Autenticação IAS RADIUS (contra Active Directory) do Windows 2003 para obter mais informações de como estabelecer a conexão de VPN de acesso remoto entre um Cisco VPN Client (4.x para Windows) e o PIX 500 Series Security Appliance 7.x.

Os Clientes VPN Não Conseguem Resolver DNS

Após o túnel ser estabelecido, se os clientes VPN não conseguirem resolver o DNS, o problema pode estar na configuração do servidor DNS no dispositivo headend (ASA/PIX). Verifique também a conectividade entre os clientes VPN e o servidor DNS. A configuração do servidor DNS deve ser feita na política de grupo e aplicada sob a política de grupo nos atributos gerais do grupo do túnel, por exemplo:


!--- Crie a política de grupo chamada vpn3000 e
!--- especifique o endereço IP do servidor DNS (172.16.1.1)
!--- e o nome do domínio (cisco.com) na política de grupo.

group-policy vpn3000 internal
group-policy vpn3000 attributes
 dns-server value 172.16.1.1
 default-domain value cisco.com


!--- Associe a política de grupo (vpn3000) ao grupo do túnel
!--- usando a política de grupo padrão.

tunnel-group vpn3000 general-attributes
 default-group-policy vpn3000

Os clientes VPN não conseguem se conectar a servidores internos pelo nome

O cliente VPN não é capaz de enviar pings para hosts ou servidores da rede interna remota ou headend pelo nome. É necessário habilitar a configuração de separação de DNS no ASA para resolver esse problema.

Separação de Túneis - Não É Possível Acessar a Internet ou Redes Excluídas

A separação de túneis permite que os clientes IPsec de acesso remoto direcionem condicionalmente pacotes para o túnel IPsec na forma criptografada ou enviem pacotes diretamente para uma interface de rede na forma de texto não criptografado, onde eles são roteados para um destino final. A separação de túneis é desabilitada por padrão, o que representa o tráfego tunnelall.

split-tunnel-policy {tunnelall | tunnelspecified | excludespecified}

Nota: A opção "excludespecified" é aceita somente em Cisco VPN Clients, e não em clientes EZVPN.

ciscoasa(config-group-policy)#split-tunnel-policy excludespecified

Consulte estes documentos para obter exemplos de configuração detalhados da separação de túneis:

Hairpinning

Este recurso é útil para o tráfego de VPN que entra em uma interface e é reenviado pela mesma interface. Se você possuir uma rede VPN com hub e raios, onde o Security Appliance é o hub e as redes VPN remotas são os raios, para que um raio se comunique com outro, o tráfego deverá ser enviado primeiro para o Security Appliance e, em seguida, reenviado para o outro raio.

Use a configuração same-security-traffic para permitir que o tráfego entre e saia da mesma interface.

securityappliance(config)# same-security-traffic permit intra-interface

Acesso à LAN Local

Os usuários de acesso remoto se conectam à VPN e são capazes de enxergar somente a rede local.

Para obter um exemplo de configuração mais detalhado, consulte PIX/ASA 7.x: Exemplo de Configuração de Permissão de Acesso à LAN Local para Clientes VPN.

Sobreposição de Redes Privadas

Problema

Se você não for capaz de acessar a rede interna após o estabelecimento do túnel, verifique o endereço IP atribuído ao cliente VPN que se sobrepõe com o da rede interna por trás do dispositivo headend.

Solução 1

Certifique-se sempre de que os endereços IP do pool que será atribuído aos clientes VPN, a rede interna do dispositivo headend e a rede interna do cliente VPN pertençam a redes diferentes. É possível atribuir a mesma rede principal com sub-redes diferentes, mas algumas vezes pode haver problemas de roteamento.

Para obter mais exemplos, consulte o Diagrama 1 e o Exemplo 1 da seção Não É Possível Acessar os Servidores na DMZ.

Solução 2

Se for necessário usar a mesma sub-rede para a rede interna do cliente VPN e a rede interna do dispositivo headend, desabilite a separação de túneis.

Por padrão, a separação de túneis está desabilitada. Desabilite a separação de túneis no dispositivo headend para fazer com que o cliente VPN envie todo o tráfego pelo túnel. Observe que o computador do cliente VPN não pode ser acessado com a rede local do cliente VPN.

Problema - Não É Possível Conectar Mais de Três Usuários de Clientes VPN

Somente três clientes VPN podem se conectar ao ASA/PIX. A conexão do quarto cliente falha. Na ocasião da falha, esta mensagem de erro é exibida:

Secure VPN Connection terminated locally by the client.
	 Reason 413: User Authentication failed.
tunnel rejected; the maximum tunnel count has been reached

Soluções

Na maioria dos casos, esse problema está relacionado a uma configuração de login simultâneo na política do grupo e ao limite máximo de sessões. Para obter mais informações, consulte a seção Configuração de Políticas de Grupo de Procedimentos de Configuração de VPN no ASDM Selecionados para a Cisco ASA 5500 Series Versão 5.2.

Configuração de Logins Simultâneos

Se a caixa de seleção Inherit estiver marcada no ASDM, somente o número padrão de logins simultâneos será permitido para o usuário. O valor padrão para os logins simultâneos é três.

Para resolver esse problema, aumente o número de logins simultâneos.

Inicie o ASDM e navegue para Configuration > VPN > Group Policy.

common_ipsec_trouble-5.gif

Selecione o valor de Group apropriado e clique no botão Edit.

common_ipsec_trouble-6.gif

Na guia General, desmarque a caixa de seleção Inherit para Simultaneous Logins em Connection Settings. Escolha um valor apropriado no campo.

common_ipsec_trouble-7.gif

Nota:  O valor mínimo para este campo é 0, o qual desabilita o login e impede o acesso de usuários.

Configuração do ASA/PIX com a CLI

Conclua estes passos para configurar o número desejado de logins simultâneos. Neste exemplo, 20 foi escolhido como o valor desejado.

ciscoasa(config)#group-policy Bryan attributes
ciscoasa(config-group-policy)#vpn-simultaneous-logins 20

Para aprender mais sobre este comando, consulte a Referência de Comandos do Cisco Security Appliance Versão 7.2.

Use o comando vpn-sessiondb max-session-limit no modo de configuração global para limitar as sessões de VPN a um valor menor do que o permitido pelo Security Appliance. Use a versão no deste comando para remover o limite de sessões. Use o comando novamente para sobrescrever a configuração atual.

vpn-sessiondb max-session-limit {session-limit}

Este exemplo mostra como definir um limite máximo de 450 sessões de VPN:

hostname#vpn-sessiondb max-session-limit 450

Configuração do Concentrador

Mensagem de erro

20932 10/26/2007 14:37:45.430 SEV=3 AUTH/5 RPT=1863 10.19.187.229
Authentication rejected: Reason = Simultaneous logins exceeded for user
handle = 623, server = (none), user = 10.19.187.229, domain = <not
specified>

Solução

Conclua estes passos para configurar o número desejado de logins simultâneos. Você também pode tentar definir Simultaneous Logins como 5 para esta AS:

Selecione Configuration > User Management > Groups > Modify 10.19.187.229 > General > Simultaneouts Logins e altere o número de logins para 5.

Problema - Não É Possível Iniciar a Sessão ou um Aplicativo e a Transferência Está Lenta Após o Estabelecimento do Túnel

Após o túnel IPsec ser estabelecido, o aplicativo ou a sessão não inicia pelo túnel.

Solução

Use o comando ping para verificar a rede ou descobrir se o servidor de aplicativos pode ser alcançado de sua rede. A causa pode ser um problema com o tamanho máximo do segmento (MSS) para os pacotes transientes que atravessam um roteador ou dispositivo PIX/ASA, especialmente segmentos de TCP com o bit SYN definido.

Cisco IOS Router

Execute estes passos para resolver esse problema:

Altere o valor de MSS na interface externa (interface da extremidade do túnel) do roteador. Prossiga com estes passos para configurar o valor do MSS:

Router>enable
Router#configure terminal
Router(config)#interface ethernet0/1
Router(config-if)#ip tcp adjust-mss 1300 
Router(config-if)#end

Estas mensagens mostram a saída de depuração do MSS do TCP:

Router#debug ip tcp transactions

Sep 5 18:42:46.247: TCP0: state was LISTEN -> SYNRCVD [23 -> 10.0.1.1(38437)]
Sep 5 18:42:46.247: TCP: tcb 32290C0 connection to 10.0.1.1:38437, peer MSS 1300, MSS is
1300
Sep 5 18:42:46.247: TCP: sending SYN, seq 580539401, ack 6015751
Sep 5 18:42:46.247: TCP0: Connection to 10.0.1.1:38437, advertising MSS 1300
Sep 5 18:42:46.251: TCP0: state was SYNRCVD -> ESTAB [23 -> 10.0.1.1(38437)]

O MSS é ajustado para 1300 no roteador conforme configurado.

Para obter mais informações, consulte PIX/ASA 7.x e IOS: Fragmentação de VPN.

PIX/ASA 7.X

Não é possível acessar a Internet ou a transferência no túnel está lenta porque mensagens de erro de tamanho de MTU e MSS são exibidas. Consulte estes documentos para resolver o problema:

PIX/ASA 7.x e IOS: Fragmentação de VPN

Problema do PIX/ASA 7.0: MSS Excedido - Os Clientes HTTP Não Conseguem Navegar para Alguns Sites

Problema - Não É Possível Iniciar o Túnel VPN do ASA/PIX

Você não consegue iniciar o túnel VPN da interface do ASA/PIX e, após o túnel ser estabelecido, o ponto remoto/cliente VPN não é capaz de enviar um ping para a interface interna do ASA/PIX no túnel VPN. Por exemplo, o cliente VPN não é capaz de iniciar uma conexão de SSH ou HTTP para a interface interna do ASA via túnel VPN.

Solução

A interface interna do PIX não poderá responder a pings enviados pela outra extremidade do túnel a menos que o comando management-access seja configurado no modo de configuração global.

PIX-02(config)#management-access inside

PIX-02(config)#show management-access
management-access inside

Nota: Este comando também ajuda a iniciar uma conexão de SSH ou HTTP para a interface interna do ASA via túnel VPN.

Nota: Esta informação se aplica também a interface da DMZ. Por exemplo, se você deseja enviar um ping para a interface de DMZ do PIX/ASA ou iniciar um túnel da interface de DMZ, o comando management-access DMZ é necessário.

PIX-02(config)#management-access DMZ

Diversos

Se você transferir a configuração de VPN do PIX/ASA versão 7.0.x para o outro Security Appliance versão 7.2.x, a seguinte mensagem de erro será recebida:

ERROR: The authentication-server-group none command has been deprecated.
The "isakmp ikev1-user-authentication none" command in the ipsec-attributes should be used
instead.

Não há mais suporte ao comando authentication-server-group na versão 7.2(1) ou posterior. Este comando foi substituído e movido para o modo de configuração de atributos gerais do grupo do túnel.

Consulte a seção isakmp ikev1-user-authentication da referência de comandos para obter mais informações sobre esse comando.

Problema

Se você habilitou a QoS em uma extremidade do túnel VPN, a seguinte mensagem de erro poderá ser recebida:

IPSEC: Received an ESP packet (SPI= 0xDB6E5A60, sequence number= 0x7F9F) from
10.18.7.11 (user= ghufhi) to
172.16.29.23 that failed anti-replay checking

Solução:

Normalmente, essa mensagem é causada quando uma extremidade do túnel está executando QoS. Isso acontece quando um pacote é detectado fora de ordem. É possível desabilitar a QoS para evitar que isso ocorra, mas você poderá ignorar esse fato desde que o tráfego atravesse o túnel.

Problema - WARNING: crypto map entry will be incomplete

Ao inserir este comando, você poderá receber a mensagem de erro mostrada na saída.

ciscoasa(config)#crypto map mymap 20 ipsec-isakmp
WARNING: crypto map entry will be incomplete

Solução:

Este é um aviso normal quando um novo mapa de criptografia é definido, um lembrete que parâmetros como access-list (endereço correspondente), transform set e peer address devem ser configurados para que ele possa funcionar. Também é normal que a primeira linha digitada para definir o mapa de criptografia não seja mostrada na configuração.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 81824