Solução de problemas comuns de L2L e VPN IPsec de acesso remoto
Introdução
Este documento descreve as soluções mais comuns para problemas de VPN IPsec.
Informações de Apoio
As soluções descritas neste documento vêm diretamente das solicitações de serviço que a equipe de suporte técnico da Cisco resolveu. Muitas dessas soluções são implementadas antes da solução de problemas detalhada de uma conexão VPN IPsec. Este documento fornece um resumo dos procedimentos comuns a serem realizados antes de começar a solucionar problemas de conexão.
Os exemplos de configuração neste documento são para uso em roteadores e dispositivos de segurança; quase todos os conceitos são aplicáveis ao VPN 3000. Consulte Troubleshooting de Segurança IP - Entendendo e Usando Comandos debug para obter uma explicação dos comandos de depuração comuns usados para solucionar problemas de IPsec no Cisco IOS® Software.
Note: A AS não transmite tráfego multicast em túneis VPN IPsec.
aviso: Muitas das soluções apresentadas neste original podem conduzir a uma perda temporária de toda a conectividade do IPSec VPN 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ê conheça a configuração da VPN IPsec nestes dispositivos da Cisco:
- Cisco IOS® Routers
-
Ferramenta de segurança do Cisco ASA 5500 Series
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
- Cisco IOS®
-
Ferramenta de segurança do Cisco ASA 5500 Series
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) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Conventions
Consulte as Convenções de dicas técnicas da Cisco para obter mais informações sobre as convenções do documento.
A configuração do IPSec VPN não funciona
Problema
- 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 estejam listadas em nenhum pedido específico, essas soluções podem ser usadas como uma lista de verificação para verificação antes de você se envolver com uma correção profunda. Todas essas soluções vêm diretamente das solicitações de serviço do TAC e resolveram vários problemas.
-
Cancele associações de segurança velhas ou existentes (os túneis)
-
Verificar se os comandos Sysopt estão presentes (somente /ASA)
-
Verifique se as ACLs estão corretas e vinculadas ao mapa de criptografia
-
Verificar os Números de Sequência e do Nome do Mapa de Criptografia
Note: Alguns comandos nestas seções são movidos para uma segunda linha devido a considerações espaciais.
Permita NAT-Traversal (a edição #1 RA VPN)
O NAT-Traversal (ou NAT-T) permite que o tráfego VPN passe por dispositivos NAT ou PAT, como o roteador SOHO Linksys. Se o NAT-T não estiver habilitado, os usuários do VPN Client geralmente parecem se conectar ao ASA sem problemas; no entanto, eles não podem acessar uma rede interna por trás do Security Appliance. Se o NAT-T no dispositivo NAT/PAT não estiver habilitado, você poderá receber a mensagem de erro regular translation creation failed for protocol 50 src inside:10.0.1.26 dst outside:10.9.694 no ASA.
Se não for possível concluir logins simultâneos a partir do mesmo endereço IP, a Conexão VPN Segura será encerrada localmente pelo cliente. Motivo 412: A mensagem de erro O peer remoto não está mais respondendo é exibida. Habilite NAT-T no dispositivo VPN headend para resolver esse erro.
Note: Com o Cisco IOS® Software Release 12.2(13)T e posterior, o NAT-T é ativado por padrão no Cisco IOS®.
O próximo comando ativa o NAT-T no Cisco Security Appliance. Os 20 neste exemplo são o tempo do keepalive (padrão).
ASA
securityappliance(config)#crypto isakmp nat-traversal 20
Os clientes devem ser modificados para que isso funcione corretamente. No Cisco VPN Client, navegue até Connection Entries e clique em Modify. Isso abre uma nova janela e você deve escolher a guia Transporte. Nessa guia, clique em Enable Transparent Tunneling e no botão de opção IPSec over UDP ( NAT/PAT ). Em seguida, clique em Salve e teste a conexão.
É importante permitir o UDP 4500 para portas NAT-T, UDP 500 e ESP pela configuração de uma ACL, pois o ASA atua como um dispositivo NAT. Consulte Configurando um túnel IPsec através de um firewall com NATpara obter mais informações sobre a configuração de ACL no ASA.
Teste a conectividade corretamente
A conectividade VPN é testada a partir de dispositivos atrás do ponto final de criptografia. Muitos usuários testam a conectividade VPN executando o comando ping do ponto de extremidade de criptografia. Embora o comando geralmente funcione para essa finalidade, é importante originar seu ping da interface correta. Se a origem do ping for incorreta, pode parecer que a conexão VPN falhou quando está funcionando corretamente. Este é um exemplo:
Roteador A ACL criptografado
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
Roteador B ACL criptografado
access-list 110 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
Neste exemplo, o ping deve ser originado de dentro da rede atrás de qualquer roteador. As ACLs de criptografia são configuradas apenas para criptografar o tráfego com esses endereços de origem. Um ping obtido das interfaces externas de um dos roteadores não é criptografado. Use as opções estendidas do comando ping no modo EXEC com privilégios para obter um ping na 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 = ½/4 ms
Imagine que os roteadores neste diagrama sejam substituídos por dispositivos de segurança ASA. O sepingusado para testar a conectividade também pode ser originado na 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
Não é recomendável direcionar o ping para a interface interna de um dispositivo de segurança. Se você precisar direcionar a interface interna com o comando ping, você deve habilitar o acesso de gerenciamento nessa interface, ou o dispositivo não responde"
securityappliance(config)#management-access inside
Quando há um problema com a conectividade, até mesmo a Fase 1 da VPN não funciona. No ASA, se a conectividade falhar, a saída do SA é semelhante a este exemplo, que indica uma possível configuração incorreta do peer de criptografia ou uma configuração incorreta da proposta de ISAKMP:
Router#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG2
O estado pode ser de MM_WAIT_MSG2 a MM_WAIT_MSG5, que denota falha na troca de estado em questão no Main Mode (MM). Crypto SA quando a Fase 1 está ativa; como este exemplo:
Router#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
Habilitar ISAKMP
Se não houver nenhuma indicação de que um túnel VPN IPsec está funcionando conforme esperado, é possível que o ISAKMP não esteja habilitado. Verifique se você habilitou o ISAKMP em seus dispositivos. Use um destes comandos para ativar o ISAKMP:
Cisco IOS®
router(config)#crypto isakmp enable
Cisco ASA (substituídoexternamente pela interface desejada):
securityappliance(config)#crypto isakmp enable outside
Você também pode receber esse erro quando habilitar o ISAKMP na interface externa:
UDP: ERROR - socket <unknown> 62465 in used ERROR: IkeReceiverInit, unable to bind to port
A causa do erro pode estar relacionada ao cliente por trás do ASA que recebe o PAT para a porta UDP 500 antes que o ISAKMP possa ser habilitado na interface. Quando a conversão PAT é removida (clear xlate), o ISAKMP pode ser habilitado. Verifique se os números de porta UDP 500 e 4500 estão reservados para a negociação de conexões ISAKMP com o peer. Quando o ISAKMP não está habilitado na interface, o cliente VPN mostra uma mensagem de erro semelhante a esta:
Secure VPN connection terminated locally by client. Reason 412: The remote peer is no longer responding
Para resolver esse erro, habilite o ISAKMP na interface de criptografia do gateway VPN.
Habilitar/Desabilitar do PFS
Nas negociações de IPsec, o Perfect Forward Secrecy (PFS) garante que cada nova chave criptográfica não esteja relacionada a nenhuma chave anterior. Ative ou desative 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 ASA / Cisco IOS®. O Perfect Forward Secrecy (PFS) é propriedade da Cisco e não é suportado em dispositivos de terceiros.
ASA:
O PFS é desabilitado por padrão e, para habilitar o PFS, execute o comando epfscom 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 PFS da configuração, execute a forma no desse comando. Uma política de grupo pode herdar um valor para o PFS de outra política de grupo. Execute a forma no desse comando para impedir a transferência de um valor.
hostname(config-group-policy)#no pfs
Roteador Cisco IOS®
- Para especificar que o IPsec deve solicitar o PFS quando novas associações de segurança forem solicitadas para a entrada do mapa de criptografia, execute o comando set pfsno modo de configuração do mapa de criptografia.
- Para especificar que o IPsec deve exigir o PFS ao receber solicitações para novas associações de segurança, execute o comando set pfsno modo de configuração de mapa de criptografia.
- Para especificar que o IPsec não deve solicitar o PFS, execute a forma no desse comando. Por padrão, o PFS não é solicitado se um grupo não for especificado com esse comando e group1 for 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
Apagar associações de segurança (túneis) antigas ou atuais
Se essa mensagem de erro ocorrer no roteador Cisco IOS®®, o SA expirou ou foi apagado. O dispositivo final do túnel remoto não sabe que usa a SA expirada para enviar um pacote (não um pacote de estabelecimento de SA). Quando um novo SA é estabelecido, a comunicação é retomada, portanto, inicie o tráfego pelo túnel para criar um novo SA 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 (SAs) ISAKMP (Fase 1) e IPsec (Fase 2), geralmente é a melhor solução para resolver problemas de VPN IPsec. Se você limpar as SAs, poderá resolver uma ampla variedade de mensagens de erro e comportamentos sem uma solução de problemas detalhada. Embora essa técnica possa ser facilmente usada em qualquer situação, é recomendável primeiro limpar as SAs após alterar ou adicionar uma configuração atual de VPN IPsec. Além disso, embora seja possível limpar apenas associações de segurança específicas, você pode se beneficiar ao limpar SAs globalmente no dispositivo. Depois que as associações de segurança forem limpas, pode ser necessário enviar tráfego pelo túnel para restabelecê-las.
aviso: A menos que você especifique quais as associações de segurança a serem canceladas, os comandos listados aqui podem cancelar todas as associações de segurança no dispositivo. Prossiga com cuidado se houver outros túneis VPN IPsec em uso.
-
Veja as associações de segurança antes que você as cancele
-
Cisco Cisco IOS®
router#show crypto isakmp sa router#show crypto ipsec sa
-
Dispositivos de segurança do Cisco ASA
securityappliance#show crypto isakmp sa securityappliance#show crypto ipsec sa
-
-
Desmarque Associações de segurança, pois cada comando pode ser inserido conforme mostrado em negrito ou inserido com as opções mostradas com eles.
-
Cisco IOS®
-
ISAKMP (Fase I)
router#clear crypto isakmp ? <0 - 32766> connection id of SA <cr>
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>
-
Dispositivos de segurança do Cisco ASA
-
ISAKMP (Fase I)
securityappliance#clear crypto isakmp sa
-
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 são frequentemente desconectados através do túnel L2L, esse problema pode ser configurado durante a vida útil no ISAKMP SA. Se ocorrer alguma discrepância no tempo de vida de ISAKMP, você poderá receber o comando%ASA-5-713092: Grupo = x.x.x.x, IP = x.x.x.x, falha durante a tentativa de rechaveamento da fase 1 devido à mensagem de erro de colisão no /ASA. O padrão é 86.400 segundos (24 horas). Como regra geral, um tempo de vida menor fornece negociações de ISAKMP mais seguras (até certo ponto), no entanto, com tempos de vida menores, o Security Appliance configura as futuras SAs de IPsec mais rapidamente.
Uma correspondência é feita quando ambas as políticas de dois peers contêm os mesmos valores de parâmetros de criptografia, hash, autenticação e Diffie-Hellman, e quando a política do peer remoto especifica um tempo de vida menor ou igual ao tempo de vida na política comparada. Se os tempos de vida não forem idênticos, o tempo de vida mais curto—da política do peer remoto—será usado, e nenhuma correspondência aceitável será encontrada, o IKE recusará a negociação e o SA do IKE não será estabelecido.
- Especifique a vida útil do SA: Este exemplo define uma vida útil de 4 horas (14400 segundos) e o padrão é 86400 segundos (24 horas).
ASA:
hostname(config)#isakmp policy 2 lifetime 14400
Roteador Cisco IOS®:
R2(config)#crypto isakmp policy 10 R2(config-isakmp)#lifetime 86400
Se o tempo de vida configurada seja excedida, você recebe esta mensagem de erro quando a conexão de VPN é terminada:
Conexão do VPN segura terminada localmente pelo cliente. Motivo 426: Tempo de vida configurada excedida.
Para resolver esse erro, defina o valor de vida útil como zero (0). Para definir o tempo de vida de uma associação de segurança IKE como infinito, a VPN deve estar sempre conectada e não termina:
hostname(config)#isakmp policy 2 lifetime 0
Você também pode desabilitar re-xauth na política de grupo para resolver o problema.
Habilitar ou Desabilitar ISAKMP Keepalives
Se você configurar as manutenções de atividades de ISAKMP, isso ajudará a evitar esporadicamente a perda de VPN de LAN para LAN ou de acesso remoto. Isso inclui clientes VPN, túneis e túneis descartados após um período de inatividade. Esse recurso permite que os endpoints de túnel monitorem a presença contínua de um peer remoto e relatem sua própria presença para esse peer. Se o peer parar de responder, o endpoint irá remover a conexão. Para que os keepalives ISAKMP funcionem, ambos os endpoints VPN devem suportá-los.
Configure os keepalives ISAKMP no Cisco IOS® executando este comando:
router(config)#crypto isakmp keepalive 15
Execute estes comandos para configurar keepalives ISAKMP em ASA Security Appliances:
Cisco ASA para o grupo de túneis denominado 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 desativar esse recurso para resolver o problema. Por exemplo, se o VPN Client estiver protegido por um firewall que evite pacotes DPD. Com o Cisco ASA, para o grupo de túneis chamado 10.165.205.222 - Desabilite o processamento de keepalive do IKE, que é 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
- Navegue para %System Root% > Program Files > Cisco Systems >VPN Client > Profilesno PC Cliente que está tendo o problema de desabilitar o keepalive do IKE e edite o arquivo PCF, onde aplicável, para a conexão.
- Altere ForceKeepAlives=0(padrão) para ForceKeepAlives=1. Keepalives são de propriedade da Cisco e não são suportados por dispositivos de terceiros.
Reinserção ou Recuperação de Chaves Pré-Compartilhadas
Em muitos casos, um erro tipográfico simples pode ser o responsável quando um túnel VPN IPsec não funciona. Por exemplo, na ferramenta de segurança, as chaves pré-compartilhadas tornam-se escondidas uma vez que são incorporadas. Esta ofuscação faz impossível considerar se uma chave está incorreta. Verifique se você inseriu todas as chaves pré-compartilhadas corretamente em cada endpoint de VPN.
Na VPN de acesso remoto, verifique se o nome de grupo válido e as chaves pré-compartilhadas foram inseridos no Cisco VPN Client. Você pode encontrar esse erro se o nome do grupo ou a(s) chave(s) pré-compartilhada(s) não corresponder(em) entre o VPN Client 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... possibly 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)
aviso: Se você remover comandos relacionados à criptografia, poderá desativar um ou todos os seus túneis VPN. Use esses comandos com cuidado e consulte a política de controle de alterações da empresa antes de remover os comandos relacionados à criptografia.
Execute estes comandos para remover e inserir novamente a chave pré-compartilhada para o peer10.0.0.1 ou o groupvpngroupno Cisco IOS®:
LAN para LAN VPN de Cisco:
router(config)#no crypto isakmp key secretkey address 10.0.0.1 router(config)#crypto isakmp key secretkey address 10.0.0.1
Acesso remoto VPN de Cisco:
router(config)#crypto isakmp client configuration group vpngroup router(config-isakmp-group)#no key secretkey router(config-isakmp-group)#key secretkey
Execute estes comandos para remover e inserir novamente a chave pré-compartilhada para o peer10.0.0.1 em /ASA Security Appliances:
Cisco 6.x:
(config)#no isakmp key secretkey address 10.0.0.1 (config)#isakmp key secretkey address 10.0.0.1
Cisco /ASA 7.x e posterior:
securityappliance(config)#tunnel-group 10.0.0.1 ipsec-attributes securityappliance(config-tunnel-ipsec)#no ikev1 pre-shared-key securityappliance(config-tunnel-ipsec)# ikev1 pre-shared-key secretkey
Chave pré-compartilhada mal combinada
O início do túnel VPN está desconectado. Esse problema ocorre devido a uma chave pré-compartilhada incompatível durante as negociações da Fase I. A mensagem MM_WAIT_MSG_6 no comando show crypto isakimp sa indica uma chave pré-compartilhada incompatível, conforme mostrado neste exemplo:
ASA#show crypto isakmp sa
Active SA: 1
Rekey SA: 0 (A tunnel reports 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: 10.7.13.20
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG_6
Para resolver esse problema, insira novamente a chave pré-compartilhada em ambos os dispositivos; a chave pré-compartilhada deve ser exclusiva e corresponder. Consulte Reinserir ou recuperar chaves pré-compartilhadas para obter mais informações.
Remoção e Reaplicação de Mapas de Criptografia
Quando você limpar as associações de segurança e isso não resolver o problema de VPN IPsec, remova e reaplique o mapa de criptografia relevante para resolver uma grande variedade de problemas que incluem quedas intermitentes de túnel VPN e falhas de alguns sites VPN.
aviso: Se você remover um mapa de criptografia de uma interface, ele removerá todos os túneis IPsec associados a esse mapa de criptografia. Continue com cuidado, consulte essas etapas e considere a política de controle de alterações da sua organização antes de prosseguir.
Execute estes comandos para remover e substituir um mapa de criptografia no Cisco IOS®:
Comece com a remoção do mapa de criptografia da relação. Execute a forma no do comando crypto map:
router(config-if)#no crypto map mymap
Continue a executar o formulário 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 peer10.0.0.1. Este exemplo mostra a configuração mínima exigida do mapa de criptografia:
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
Execute estes comandos para remover e substituir um mapa de criptografia no ASA. Comece com a remoção do mapa de criptografia da relação. Execute a forma no do comando crypto map:
securityappliance(config)#no crypto map mymap interface outside
Continue a executar o formulário 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 do peer10.0.0.1. Este exemplo mostra a configuração mínima exigida do mapa de criptografia:
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
Se você remover e reaplicar o mapa de criptografia, isso também resolverá o problema de conectividade se o endereço IP do headend tiver sido alterado.
Verificar se os comandos Sysopt estão presentes (somente ASA)
Os comandos sysopt connection permit-ipsec e sysopt connection permit-vpn permitem que pacotes de um túnel IPsec e os respectivos payloads ignorem as ACLs de interface no dispositivo de segurança. 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 e anterior, o comando sysopt relevante para essa situação é sysopt connection permit-ipsec.
- No Security Appliance Software versão 7.1(1) e posterior, o comando sysopt relevante para essa situação é sysopt connection permit-vpn.
- Na versão 6.x, essa funcionalidade está desativada por padrão. No /ASA 7.0(1) e posterior, essa funcionalidade está ativada por padrão. Execute estes comandos show para determinar se o comando relevantsysopt está habilitado em seu dispositivo:
Cisco ASA:
securityappliance# show running-config all 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 is enabled !--- This device is running 7.2(2)
Execute este comando para ativar o comando correctsysopt para seu dispositivo:
Cisco ASA:
securityappliance(config)#sysopt connection permit-vpn
Se você não quiser executar o comando sysopt connection, permita explicitamente o tráfego necessário da origem para o destino. Por exemplo, de LAN remota para LAN local do dispositivo remoto e "porta UDP 500" para interface externa do dispositivo remoto para interface externa do dispositivo local, na ACL externa.
Verificação da Identidade de ISAKMP
As falhas de negociação de IKE em VPNs IPsec geralmente resultam da falha de um peer em reconhecer a identidade de seu parceiro, esse é o caminho. Quando dois peers usam IKE para estabelecer associações de segurança IPsec, cada peer envia sua identidade ISAKMP ao 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 do ISAKMP da unidade de 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 definir o ID da Fase 2 a ser enviado ao peer, execute o comando isakmp identityno modo de configuração global:
crypto isakmp identity address !--- If the RA or L2L (site-to-site) VPN tunnels connect !--- with pre-shared key as authentication type
OU:
crypto isakmp identity auto !--- If the RA or L2L (site-to-site) VPN tunnels connect !--- with ISAKMP negotiation by connection type; IP address for !--- preshared key or cert DN for certificate authentication.
OU:
crypto isakmp identity hostname !--- Uses the fully-qualified domain name of !--- the host exchange ISAKMP identity information (default). !--- This name comprises the hostname and the domain name.
Se o túnel VPN não iniciar após uma mudança de configuração do ASA com a ferramenta de migração de configuração do ASA; estas mensagens aparecem no registro:
[IKEv1]: O grupo = x.x.x.x, IP= x.x.x.x, Stale PeerTblEntry encontrado, removendo!
[IKEv1]: Grupo = x.x.x.x, IP= x.x.x.x, removendo o par da tabela do correlator falhada, sem correspondência!
[IKEv1]: Grupo = x.x.x.x, IP= x.x.x.x, construct_ipsec_delete(): Nenhum SPI para identificar a fase 2 SA!
[IKEv1]: Grupo = x.x.x.x, IP= x.x.x.x, removendo o par da tabela do correlator falhada, sem correspondência!
Verificação do Timeout de Ociosidade/Sessão
Se o timeout de ociosidade estiver definido como 30 minutos (padrão), ele desconectará o túnel após 30 minutos se nenhum tráfego passar. O cliente VPN é desconectado após 30 minutos independentemente do parâmetro de timeout ocioso e recebe o erro PEER_DELETE-IKE_DELETE_UNSPECIFIED.
Configure idle timeoutandsession timeoutasnone para tornar o túnel sempre up e para que o túnel nunca seja descartado, mesmo quando dispositivos de terceiros forem usados.
ASA
Execute o comando evpn-idle-timeoutno 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 um tempo máximo para conexões VPN com o comando vpn-session-timeout no modo de configuração de group-policy ou no modo de configuração do nome de usuário:
hostname(config)#group-policy DfltGrpPolicy attributes hostname(config-group-policy)#vpn-session-timeout none
Quando você tem o túnel-todoconfigurado, você não precisa configuraridle-timeoutporque, mesmo se você configurar o VPN-idle timeout, ele não funciona como todos os processos de tráfego através do túnel (uma vez que o túnel-all está configurado).
Portanto, o tráfego (ou mesmo o tráfego gerado pelo PC) não permite que ocorra o timeout de ociosidade.
Roteador Cisco IOS®
Execute o comando crypto ipsec security-association idle-timeno modo de configuração global ou no modo de configuração do mapa de criptografia para configurar o temporizador de ociosidade da AS do IPsec. Por padrão, esses temporizadores estão desabilitados:
crypto ipsec security-association idle-time seconds
O tempo é medido em segundos, que o temporizador ocioso permite que um par inativo mantenha uma SA. Os valores válidos para o argumento seconds variam entre 60 e 86.400.
Verifique se as ACLs estão corretas e vinculadas ao mapa de criptografia
Há duas listas de acesso usadas em uma configuração de VPN IPsec típica. Uma lista de acessos é usada para isentar o tráfego que é destinado para o túnel VPN do processo NAT. A outra lista de acessos define que tráfego a criptografado; isso inclui uma ACL criptografada em uma configuração de LAN para LAN ou uma ACL de túnel dividido em uma configuração de acesso remoto. Quando essas ACLs são configuradas incorretamente ou perdidas, o tráfego flui em uma direção pelo túnel VPN ou não é enviado pelo túnel.
Certifique-se de vincular a ACL de criptografia com o mapa de criptografia executando o comando crypto map match address no modo de configuração global. Verifique se você configurou todas as listas de acesso para concluir suas configurações de VPN IPsec e se essas listas de acesso definem o tráfego correto. Esta lista contém itens para validar quando você suspeita que uma ACL é a causa de problemas com a VPN IPsec.
Confirme a isenção de NAT e as ACLs de criptografia especificam o tráfego correto. Se você tiver vários túneis VPN e várias ACLs criptografadas, certifique-se de que essas ACLs não se sobreponham. Verifique também se o dispositivo está configurado para usar a ACL de isenção de NAT. Em um roteador, isso significa que você está executando o comando route-map. No ASA, você está executando o comando enat (0). Uma isenção de NAT ACL é exigida para configurações do LAN para LAN e do acesso remoto.
No próximo exemplo, um roteador Cisco IOS® é configurado para isentar o tráfego enviado entre192.168.100.0 /24e192.168.200.0 /24ou192.168.1.0 /24do NAT. O tráfego destinado para qualquer outro lugar é sujeito à sobrecarga 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
As ACLs de isenção de NAT funcionam somente com o endereço IP ou redes IP, como os exemplos mencionados (access-list noNAT), e devem ser idênticas às ACLs de mapa de criptografia. As ACLs de isenção de NAT não funcionam com números de porta (por exemplo, 23, 25 e assim por diante). Em um ambiente VOIP, onde as chamadas de voz entre redes são comunicadas através da VPN, as chamadas de voz não operam se as ACLs NAT 0 não estiverem configuradas corretamente. Antes da solução de problemas, é recomendável verificar o status da conectividade da VPN, pois o problema pode ser devido à configuração incorreta das ACLs isentas de NAT.
Você pode receber a mensagem de erro mostrada se houver erro de configuração nas ACLs de isenção de NAT (nat 0).
%ASA-3-305005: No translation group found for udp src Outside:x.x.x.x/p dst Inside:y.y.y.y/p
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
Se a isenção de NAT (nat 0) não funcionar corretamente, tente removê-la e execute o comandoNAT 0. Certifique-se de que as ACLs não sejam de trás para frente e sejam do tipo correto. As ACLs de isenção de criptografia e NAT para configurações LAN a LAN devem ser escritas da perspectiva do dispositivo onde a ACL está configurada. Portanto, as ACLs devem alcançar outras. Neste exemplo, um túnel de LAN para LAN foi configurado entre 192.168.100.0 /24 e 192.168.200.0 /24.
Roteador A ACL criptografado:
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
Roteador B ACL criptografado:
access-list 110 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
Embora não ilustrado, o mesmo conceito se aplica aos ASA Security Appliances. No ASA, as ACLs de túnel dividido para configurações de Acesso Remoto devem ser as listas de acesso padrãoque permitem o tráfego para a rede onde os clientes VPN precisam de acesso. Os roteadores Cisco IOS® podem usar a ACL estendida para túneis divididos. Na lista de acesso estendida, usar 'any' na origem na ACL de split tunnel é semelhante a disable split tunnel. Use apenas redes de origem na ACL estendida para o túnel dividido.
Exemplo correto:
access-list 140 permit ip 10.1.0.0 0.0.255.255 10.18.0.0 0.0.255.255
Exemplo incorreto:
access-list 140 permit ip any 10.18.0.0 0.0.255.255
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 ASA
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
Configuração da excessão de NAT na versão ASA 8.3 para o túnel do VPN de Site-para-Site:
Uma VPN site a site deve ser estabelecida entre HOASA e BOASA com ambos os ASAs com a versão 8.3. A configuração de isenção de NAT no HOASA é semelhante a esta:
object network obj-local subnet 192.168.100.0 255.255.255.0 object network obj-remote subnet 192.168.200.0 255.255.255.0 nat (inside,outside) 1 source static obj-local obj-local destination static obj-remote objremote
Verificação das Políticas de ISAKMP
Se o túnel IPsec não for UP, verifique se as políticas de ISAKMP correspondem aos 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 conseguirem estabelecer o túnel com o dispositivo de extremidade remota, verifique se os dois pares contêm os mesmos valores de parâmetro de criptografia, hash, autenticação e Diffie-Hellman. Verifique quando a política de 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 SA não será estabelecida.
"Error: Unable to remove Peer TblEntry, Removing peer from peer table failed, no match!"
Este é um exemplo da mensagem de log detalhada:
4|Mar 24 2010 10:21:50|713903: IP = X.X.X.X, Error: Unable to remove PeerTblEntry 3|Mar 24 2010 10:21:50|713902: IP = X.X.X.X, Removing peer from peer table failed, no match! 3|Mar 24 2010 10:21:50|713048: IP = X.X.X.X, Error processing payload: Payload ID: 1 4|Mar 24 2010 10:21:49|713903: IP = X.X.X.X, Information Exchange processing failed 5|Mar 24 2010 10:21:49|713904: IP = X.X.X.X, Received an un-encrypted NO_PROPOSAL_CHOSEN notify message, drop
Essa mensagem geralmente é exibida devido a políticas de ISAKMP incompatíveis ou uma instrução NAT 0 ausente. Além disso, esta mensagem aparece:
Error Message %ASA-6-713219: Queueing KEY-ACQUIRE messages to be processed when P1 SA is complete.
Essa mensagem indica que as mensagens da Fase 2 estão na fila após a conclusão da Fase 1. Essa mensagem de erro ocorre devido a um destes motivos:
-
Má combinação na fase em alguns dos peers
-
A ACL bloqueia os pares após a conclusão da fase 1
Essa mensagem geralmente é exibida após a mensagem de erro Removing peer from peer table failed, no match!. Se o Cisco VPN Client não conseguir conectar o dispositivo headend, o problema pode ser a incompatibilidade da Política ISAKMP. O dispositivo headend deve corresponder a uma das propostas IKE do Cisco VPN Client. Para a política ISAKMP e o conjunto de transformação IPsec usados no ASA, o Cisco VPN Client não pode usar uma política com uma combinação de DES e SHA. Se você usa DES, deve usar MD5 para o algoritmo de hash ou pode usar outras combinações, como 3DES com SHA e 3DES com MD5.
Verifique se o roteamento está correto
Certifique-se de que seus dispositivos de criptografia, como roteadores e ASA Security Appliances, tenham as informações de roteamento adequadas para enviar o tráfego pelo túnel VPN. Se houver outros roteadores atrás do dispositivo de gateway, verifique se esses roteadores podem acessar o túnel e quais redes estão do outro lado. Um componente chave do roteamento em uma implantação de VPN é a Injeção de Rota Reversa (RRI). O RRI coloca entradas dinâmica 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 estão instaladas e para outros dispositivos na rede, pois as rotas instaladas pelo RRI podem ser redistribuídas através de protocolos de roteamento como EIGRP ou OSPF.
Em uma configuração de LAN para LAN, é importante que cada endpoint tenha uma ou mais rotas para as redes onde devem criptografar o tráfego. Neste exemplo, o Roteador A deve ter rotas para as redes atrás do Roteador B até 10.89.129.2. O Roteador B deve ter uma rota semelhante a192.168.100.0 /24. A primeira maneira de garantir que cada roteador saiba a(s) rota(s) apropriada(s) é configurar rotas estáticas para cada rede de destino. Por exemplo, o Roteador A pode ter estas declaraçõ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 o roteador A foi substituído por um ASA, a configuração pode ficar assim:
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 um grande número de redes atrás de cada endpoint, a configuração de rotas estáticas se tornará difícil de manter. Em vez disso, recomenda-se que você use a injeção de rota reversa. O RRI coloca as rotas da tabela de roteamento para todas as redes remotas listadas na ACL criptografada. Por exemplo, a criptografia ACL e o mapa de criptografia do Roteador A podem parecer como este:
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 o Roteador A foi substituído pelo ASA, a configuração pode ser assim:
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 do acesso remoto, as mudanças de roteamento não são sempre necessárias. Ainda assim, se houver outros roteadores atrás do roteador do gateway VPN ou do Security Appliance, esses roteadores devem aprender o caminho para os clientes VPN. Neste exemplo, imagine que os clientes VPN recebem endereços no intervalo de 10.0.0.0 /24quando se conectam.
Se nenhum protocolo de roteamento está no uso entre o Gateway e o outro roteador, as rotas estáticas podem ser usadas em roteadores tais como Roteador 2:
ip route 10.0.0.0 255.255.255.0 192.168.100.1
Se um protocolo de roteamento tal como o EIGRP ou o OSPF está no uso entre o Gateway e outros roteadores, recomenda-se que o Reverse Route Injection esteja usado como descrito. O RRI adiciona automaticamente rotas para o cliente VPN à tabela de roteamento do Gateway. Estas rotas podem então ser distribuídas às outras rotas na rede.
Roteador Cisco IOS®:
crypto dynamic-map dynMAP 10 set transform-set mySET reverse-route crypto map myMAP 60000 ipsec-isakmp dynamic dynMAP
Dispositivo de segurança do Cisco ASA:
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
O problema de roteamento ocorre se o pool de endereços IP atribuídos aos clientes VPN são sobrepostos com as redes internas do dispositivo headend. Para obter mais informações, consulte a seção Redes privadas sobrepostas.
Verifique se o conjunto de transformação está correto
Certifique-se de que os algoritmos de criptografia IPsec e hash usados pelo conjunto de transformação em ambas as extremidades sejam os mesmos. Consulte a seção CommandReferencesdo guia de configuração do Cisco Security Appliance para obter mais informações. Para a política ISAKMP e o conjunto de transformação IPsec usados no ASA, o Cisco VPN Client não pode usar uma política 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.
Verifique se o número de sequência do mapa de criptografia, o nome e o mapa de criptografia são aplicados à interface direita onde o início/fim do túnel IPsec
Se peers estáticos e dinâmicos forem configurados no mesmo mapa de criptografia, a ordem das entradas do mapa de criptografia será crítica. O número de sequência da entrada do mapa de criptografia dinâmico deve ser maior que todas as outras entradas do mapa de criptografia estático. Se as entradas estáticas forem numeradas acima das entradas dinâmicas, as conexões com esses peers falharão e as depurações mostradas 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!
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 uma entrada dinâmica. A entrada dinâmica tem o número de sequência mais alto e a sala foi deixada para adicionar 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 ciscothe
Os nomes de mapa de criptografia diferencia entre maiúsculas e minúsculas. Essa mensagem de erro também pode ser vista quando a sequência de mapa de criptografia dinâmica está incorreta, o que faz com que o peer atinja o mapa de criptografia errado. Isso também é causado por uma lista de acesso de criptografia incompatível que define o tráfego:%ASA-3-713042: Iniciador IKE incapaz de encontrar a política:
Em um cenário onde vários túneis VPN são terminados na mesma interface, crie um mapa de criptografia com o mesmo nome (somente um mapa de criptografia é permitido por interface), mas com um número de sequência diferente. Isso vale para o roteador e o ASA. Consulte o ASA: Adicionar um novo túnel ou acesso remoto a uma VPN L2L existente - Cisco para obter mais informações sobre a configuração do mapa de criptografia para cenários de VPN L2L e de acesso remoto.
Verifique se o endereço IP do peer está correto
Crie e gerencie o banco de dados de registros específicos da conexão para IPsec. Para uma configuração de VPN IPsec LAN a LAN (L2L) do ASA Security Appliance, especifique o<nome>do grupo de túneis como o endereço IP do ponto remoto (extremidade do túnel remoto) no comando tunnel-group <nome> type ipsec-l2l. O endereço IP do peer deve corresponder ao nome do grupo de túneis e aos comandos do conjunto de mapas de criptografia address. Quando você configura a VPN com o ASDM, ele gera o nome do grupo de túneis automaticamente com o endereço IP do peer correto. Se o endereço IP do peer não estiver configurado corretamente, os logs poderão conter esta mensagem, que pode ser resolvida pela configuração apropriada do endereço IP do peer:
[IKEv1]: Group = DefaultL2LGroup, IP = x.x.x.x, ERROR, had problems decrypting packet, probably due to mismatched pre-shared key. Aborting
Quando o endereço IP do peer não foi configurado corretamente na configuração criptografada do ASA, o ASA não pode estabelecer o túnel VPN e trava somente no estágioMM_WAIT_MSG4. Para resolver esse problema, corrija o endereço IP do peer na configuração. Esta é a saída do comando show crypto isakmp saquando o túnel VPN trava no estado MM_WAIT_MSG4:
hostname#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG4
Verifique o grupo de túneis e os nomes do grupo
%ASA-3-713206: Tunnel Rejected: Conflicting protocols specified by tunnel-group and group-policy
Esta mensagem aparece quando um túnel é descartado porque o túnel permitido especificado na política de grupo é diferente do túnel permitido na configuração do grupo de túneis.
group-policy hf_group_policy attributes vpn-tunnel-protocol l2tp-ipsec username hfremote attributes vpn-tunnel-protocol l2tp-ipsec Both lines read: vpn-tunnel-protocol ipsec l2tp-ipsec
Ativar IPSec Na política de grupo padrão para os protocolos existentes na política de grupo padrão.
group-policy DfltGrpPolicy attributes vpn-tunnel-protocol L2TP-IPSec IPSec webvpn
Desabilite XAUTH para peers L2L
Se um túnel de LAN para LAN e um túnel de VPN de acesso remoto forem configurados no mesmo mapa de criptografia, o peer de LAN para LAN é solicitado para informações XAUTH, e o túnel de LAN para LAN falha com CONF_XAUTH na saída do comando show crypto isakmp sacommand. Este é um exemplo da saída SA:
Router#show crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id slot status X.X.X.X Y.Y.Y.Y CONF_XAUTH 10223 0 ACTIVE X.X.X.X Z.Z.Z.Z CONF_XAUTH 10197 0 ACTIVE
Esse problema aplica-se apenas ao Cisco IOS®, em que o ASA não é afetado por esse problema, pois ele usa grupos de túneis. Execute a palavra-chave no-xauthquando você inserir a chave ISAKMP, para que o dispositivo não solicite ao peer as informações XAUTH (nome de usuário e senha). Esta palavra-chave desabilita o XAUTH para peers IPsec estáticos. Execute um comando semelhante a este no dispositivo que tem o L2L e o RA VPN configurados no mesmo mapa de criptografia:
router(config)#crypto isakmp key cisco123 address 172.22.1.164 no-xauth
No cenário em que o ASA atua como o Easy VPN Server, o cliente Easy VPN não pode se conectar ao headend devido a um problema de Xauth. Desative a autenticação de usuário no ASA para resolver o problema:
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 encontrar mais informações sobre o comando isakmp ikev1-user-authenticationcommand.
Pool de VPN esgotado
Quando a escala dos endereços IP atribuídos ao pool VPN não é suficiente, você pode estender a disponibilidade dos endereços IP de duas maneiras:
-
Remova o intervalo existente e defina o novo intervalo:
CiscoASA(config)#no ip local pool testvpnpool 10.76.41.1-10.76.41.254 CiscoASA(config)#ip local pool testvpnpool 10.76.41.1-10.76.42.254
-
Quando as sub-redes não contíguas devem ser adicionadas ao pool VPN, você pode definir dois pools VPN separados e especificá-los em "atributos de grupo de túneis ". Este é um exemplo:
CiscoASA(config)#ip local pool testvpnpoolAB 10.76.41.1-10.76.42.254 CiscoASA(config)#ip local pool testvpnpoolCD 10.76.45.1-10.76.45.254 CiscoASA(config)#tunnel-group test type remote-access CiscoASA(config)#tunnel-group test general-attributes CiscoASA(config-tunnel-general)#address-pool (inside) testvpnpoolAB testvpnpoolCD CiscoASA(config-tunnel-general)#exit
A ordem em que você especifica os pools é importante porque o ASA aloca endereços desses pools na ordem em que os pools aparecem nesse comando. As configurações dos pools de endereços no comando group policy address pools sempre substituem as configurações do pool local no comando tunnel-group address-pool.
Problemas de latência no tráfego do cliente VPN
Quando houver problemas de latência em uma conexão VPN, verifique estas condições para resolver isso:
-
Verifique se o MSS do pacote pode ser mais reduzido.
-
Se IPsec/tcp for usado em vez de IPsec/udp, configure preserve-vpn-flow.
-
Recarregue o Cisco ASA.
Os clientes VPN não podem se conectar com o ASA
Problema
Os clientes VPN Cisco não podem autenticar quando o Xauth é usado com o servidor Radius.
Solução
Às vezes, Xauth expira, você pode aumentar o valor de timeout para o servidor AAA para resolver esse 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 clientes da Cisco VPN não conseguem fazer a autenticação quando o X-AUTH é usado com o servidor Radius.
Solução
Inicialmente, certifique-se de que a autenticação funcione corretamente. Para reduzir o problema, verifique primeiro a autenticação com o banco de dados local no ASA.
tunnel-group tggroup general-attributes
authentication-server-group none
authentication-server-group LOCAL
exit
Se isso funcionar, o problema está relacionado à configuração do servidor Radius. Verifique a conectividade do servidor Radius do ASA. Se o ping for executado sem nenhum problema, verifique a configuração relacionada ao Radius no ASA e a configuração do banco de dados no servidor Radius. Você pode executar o comando debug radius para solucionar problemas relacionados ao raio. Para obter um exemplo de saída do debug radius, consulte este Exemplo de saída. Antes de usar o comando debug no ASA, consulte esta mensagem deAviso da documentação.
O cliente VPN interrompe a conexão com frequência na primeira tentativa ou "Conexão VPN segura encerrada pelo par. Motivo 433" ou "Conexão VPN segura encerrada pelo Motivo 433:(Motivo não especificado pelo peer)"
Problema
Os usuários do Cisco VPN Client recebem esse erro quando tentam fazer a conexão com o dispositivo VPN de headend.
- O cliente VPN descarta a conexão frequentemente na primeira tentativa.
- Conexão VPN de segurança encerrada pelo motivo 433 do par.
- Conexão VPN Segura encerrada pelo Motivo de Mesmo Nível 433:(Motivo Não Especificado pelo Mesmo Nível).
- Tentativa de atribuir a rede ou o endereço IP de broadcast, removendo (xxxx) do pool.
Solução 1
Esse problema pode estar relacionado à atribuição do pool IP por meio do ASA, do servidor Radius, do servidor DHCP ou do servidor Radius que atua como um servidor DHCP. Execute o comando debug cryptopara verificar se a máscara de rede e os endereços IP estão corretos. Além disso, confirme se o pool não inclui o endereço de rede e o endereço de broadcast. Os servidores Radius devem atribuir os endereços IP apropriados aos clientes.
Solução 2
Esse problema também ocorre devido à falha da autenticação estendida. Você deve verificar o servidor AAA para corrigir erros. Verifique a senha de autenticação do servidor no servidor e no cliente. Recarregar o servidor AAA pode resolver esse problema.
Solução 3
Uma outra ação alternativa para esta edição é desabilitar a característica da detecção de riscos. Quando há várias retransmissões para Associações de Segurança (SAs) diferentes e incompletas, o ASA com o recurso de detecção de ameaças habilitado pensa que ocorreu um ataque de verificação e as portas VPN são marcadas como o principal infrator. Desative o recurso de detecção de ameaças, pois isso pode causar problemas de sobrecarga no processamento do ASA. Execute estes comandos para desativar a detecção de ameaças:
no threat-detection basic-threat no threat-detection scanning-threat shun no threat-detection statistics no threat-detection rate
Isso pode ser usado como uma solução alternativa para verificar se isso resolve o problema. Certifique-se de desabilitar a detecção de ameaças no Cisco ASA, pois isso compromete vários recursos de segurança, como mitigação das tentativas de verificação, DoS com SPI inválido, pacotes que falham na inspeção de aplicativos e sessões incompletas.
Solução 4
Esse problema também ocorre quando um conjunto de transformação não está configurado corretamente e uma configuração adequada do conjunto de transformação resolve o problema.
O acesso remoto e os usuários EZVPN conectam ao VPN mas não podem alcançar recursos externos
Problema
- Os usuários de acesso remoto não têm conectividade com a Internet depois de se conectarem à VPN.
- Os usuários de acesso remotos não podem alcançar os recursos situados atrás de outros VPN no mesmo dispositivo.
- Os usuários de acesso remotos podem acessar somente a rede local.
Soluções
Tente estas soluções para resolver o problema:
Não É Possível Acessar os Servidores na DMZ
No entanto, quando o cliente VPN é estabelecido, o túnel IPsec com o dispositivo de headend da VPN (roteador ASA/Cisco IOS®), os usuários do cliente VPN podem acessar os recursos da rede INSIDE (10.10.10.0/24). eles não podem acessar a rede DMZ (10.1.1.0/24).
Diagrama
Verifique se a configuração Split Tunnel, NO NAT foi adicionada ao dispositivo headend para acessar os recursos na rede DMZ.
Configuração do ASA
Esta configuração mostra como configurar a isenção de NAT para a rede DMZ para permitir que os usuários de VPN acessem a rede DMZ:
object network obj-dmz subnet 10.1.1.0 255.255.255.0 object network obj-vpnpool subnet 192.168.1.0 255.255.255.0 nat (inside,dmz) 1 source static obj-dmz obj-dmz destination static obj-vpnpool obj-vpnpool
Depois de adicionar uma nova entrada para a configuração NAT, limpe a conversão NAT.
Clear xlate Clear local
Verificar
Se o túnel estiver estabelecido, vá para o Cisco VPN Client e escolhaStatus > Route Os detalhes para validar as rotas seguras são mostrados para as redes DMZ e INSIDE.
Consulte o ASA: Add a New Tunnel or Remote Access to an Existing L2L VPN - Cisco para obter as etapas necessárias para adicionar um novo túnel VPN ou uma VPN de acesso remoto a uma configuração de VPN L2L já existente. Você também pode consultar o ASA: Permitir separação de túneis para clientes VPN no Exemplo de configuração do ASAPara obter instruções passo a passo sobre como permitir que clientes VPN acessem a Internet enquanto estão em um túnel para um Cisco 5500 Series Adaptive Security Appliance (ASA).
Os Clientes VPN Não Conseguem Resolver DNS
Depois que o túnel é estabelecido, se os clientes VPN não podem resolver o DNS, o problema pode estar relacionado à configuração do servidor DNS no dispositivo headend (ASA). Verifique a conectividade entre os clientes VPN e o servidor DNS. As configurações do servidor DNS devem ser configuradas sob a política de grupo e aplicadas sob a política de grupo nos atributos gerais do grupo de túneis:
!--- Create the group policy named vpn3000 and !--- specify the DNS server IP address(172.16.1.1) !--- and the domain name(cisco.com) in the group policy. group-policy vpn3000 internal group-policy vpn3000 attributes dns-server value 172.16.1.1 default-domain value cisco.com !--- Associate the group policy(vpn3000) to the tunnel group !--- with the default-group-policy. tunnel-group vpn3000 general-attributes default-group-policy vpn3000
Os clientes VPN não podem se conectar a servidores internos por nome
O cliente VPN não pode fazer ping nos hosts ou servidores da rede interna remota ou de headend pelo nome. Você deve habilitar a configuração split-dns no ASA para resolver esse problema.
Separação de Túneis - Não É Possível Acessar a Internet ou Redes Excluídas
O túnel dividido permite que os clientes IPsec de acesso remoto direcionem condicionalmente pacotes pelo túnel IPsec na forma criptografada ou para uma interface de rede na forma descriptografada de texto claro, onde são roteados para seu destino final.
O túnel dividido está desabilitado por padrão, o que pode ser visto executa o commandtunnelalltraffic.
split-tunnel-policy {tunnelall | tunnelspecified | excludespecified}
A opção excludespecified é suportada somente para Cisco VPN Clients e não para EZVPN Clients.
ciscoasa(config-group-policy)#split-tunnel-policy excludespecified
Consulte estes documentos para obter exemplos de configuração detalhados do split-tunnel:
Solução Hairpin
Esse recurso é útil para o tráfego VPN que entra em uma interface, mas é então roteado para fora da mesma interface. Por exemplo, em uma rede VPN hub e spoke em que o dispositivo de segurança é o hub e as redes VPN remotas são spokes. O tráfego de comunicação spoke-to-spoke deve entrar no dispositivo de segurança e sair novamente para o outro spoke. Execute 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 do LAN local
Os usuários de acesso remoto se conectam à VPN e podem se conectar somente a redes locais. Para obter um exemplo de configuração mais detalhado, consulte o ASA: Permita o acesso do LAN local para clientes VPN.
Sobreposição de Redes Privadas
Problema
Se você não puder 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 à rede interna por trás do dispositivo headend.
Solução
Verifique se os endereços IP no pool atribuído aos clientes VPN, a rede interna do dispositivo headend e a rede interna do cliente VPN estão em redes diferentes. Você pode atribuir a mesma rede principal a sub-redes diferentes, no entanto, às vezes ocorrem problemas de roteamento. Para obter mais exemplos, consulte a seçãoDiagramandExampleof theUnable to Access the Servers in DMZ.
Unable to Connect m=More than Three VPN Client Users (Não foi possível conectar m=Mais de três usuários de cliente VPN)
Problema
Apenas três clientes VPN podem se conectar ao ASA/ e a conexão para o 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 logon simultâneo na política de grupo e ao limite máximo de sessão. Tente estas soluções para resolver o problema:
Configuração de Logins Simultâneos
Se a caixa de seleção Herdar no ASDM estiver marcada, apenas o número padrão de logins simultâneos será permitido para o usuário. O valor padrão para logons simultâneos é 3. Para resolver esse problema, aumente o valor para logons simultâneos.
-
Inicie o ASDM e navegue até Configuration > VPN > Group Policy.
-
Escolha o Group apropriado e clique no botão Edit.
-
Na guia General, desmarque a caixa de seleção Inherit para Simultaneous Logins em Connection Settings. Escolha um valor apropriado no campo.
O valor mínimo para esse campo é 0, que desabilita os logons e impede o acesso do usuário. Quando você efetua login com a mesma conta de usuário de um PC diferente, a sessão atual (a conexão estabelecida de outro PC com a mesma conta de usuário) é encerrada e a nova sessão é estabelecida. Esse é o comportamento default e é independente dos logons simultâneos de VPN.
Configure o ASA com a CLI
Siga estas etapas 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 saber mais sobre esse comando, consulte a Referência de Comandos do Cisco Security Appliance. Execute o comando evpn-sessiondb max-session-limitno modo de configuração global para limitar as sessões VPN a um valor menor do que o permitido pelo Security Appliance. Execute a conversão desse comando para remover o limite de sessão e execute o comando novamente para substituir 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
Configurar
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
Siga estas etapas para configurar o número desejado de logins simultâneos. Você também pode definir os logons simultâneos como 5 para esse SA. Escolha Configuration > User Management > Groups > Modify 10.19.187.229 > General > Simultaneous Logins e altere o número de logins para 5.
Incapaz de iniciar a sessão ou uma aplicação e de retardar transferência após o estabelecimento de túnel
Problema
Após o túnel IPsec ser estabelecido, o aplicativo ou a sessão não inicia pelo túnel.
Soluções
Execute o comando ping para verificar a rede ou descobrir se o servidor de aplicativos está acessível a partir da sua rede. Pode ser um problema com o tamanho máximo de segmento (MSS) para pacotes temporários que atravessam um roteador ou dispositivo /ASA, especificamente segmentos TCP com o bit SYN definido.
Cisco IOS® Router – Altere o valor de MSS na interface externa (Tunnel End Interface) do roteador
Execute estes comandos para alterar o valor de MSS na interface externa (interface de extremidade de túnel) do roteador:
Router>enable Router#configure terminal Router(config)#interface ethernet0/1 Router(config-if)#ip tcp adjust-mss 1300 Router(config-if)#end
Essas mensagens exibem a saída de depuração para TCP MSS:
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 o ASA e o Cisco IOS®: Fragmentação VPN.
ASA – Consulte a documentação do /ASA
Não é possível acessar a Internet corretamente ou a transferência é lenta pelo túnel porque ela apresenta mensagens de erro de tamanho de MTU e problemas de MSS. Consulte este documento para resolver o problema:
Não é possível iniciar o túnel VPN a partir do ASA
Problema
Você não pode iniciar o túnel VPN a partir da interface ASA e após o estabelecimento do túnel. O cliente VPN/final remoto não pode fazer ping na interface interna do ASA no túnel VPN. Por exemplo, o cliente VPN não pode iniciar uma conexão SSH ou HTTP para ASAs dentro da interface em um túnel VPN.
Solução
Não é possível fazer ping na interface interna a partir da outra extremidade do túnel, a menos que o comando management-access esteja configurado no modo de configuração global.
ASA-02(config)#management-access inside ASA-02(config)#show management-access management-access inside
Esse comando também auxilia na iniciação do ssh ou na conexão http para a interface interna do ASA através de um túnel VPN. As informações também são verdadeiras para interfaces DMZ. Por exemplo, se você deseja fazer ping na interface DMZ de /ASA ou iniciar um túnel a partir da interface DMZ, é necessário executar o comando management-access DMZ.
ASA-02(config)#management-access DMZ
Se o cliente VPN não conseguir se conectar, verifique se as portas ESP e UDP estão abertas. No entanto, se essas portas não estiverem abertas, tente se conectar no TCP 10000 selecionando essa porta na entrada de conexão do VPN Client. Clique com o botão direito em Modify > Transport Tab > IPsec over TCP.
Incapaz de Passar o Tráfego Através do Túnel VPN
Problema
Você não pode passar o tráfego por um túnel VPN.
Solução
Esse problema também pode ocorrer quando os pacotes ESP são bloqueados. Para resolver esse problema, reconfigure o túnel VPN. Também pode ocorrer quando os dados não são criptografados, mas apenas descriptografados pelo túnel VPN, como mostrado nesta saída:
ASA# sh crypto ipsec sa peer x.x.x.x
peer address: y.y.y.y
Crypto map tag: IPSec_map, seq num: 37, local addr: x.x.x.x
access-list test permit ip host xx.xx.xx.xx host yy.yy.yy.yy
local ident (addr/mask/prot/port): (xx.xx.xx.xx/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (yy.yy.yy.yy/255.255.255.255/0/0)
current_peer: y.y.y.y
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 393, #pkts decrypt: 393, #pkts verify: 393
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
Para resolver esse problema, verifique as seguintes condições:
-
Se as listas de acesso de criptografia corresponderem ao local remoto, e as listas de acesso NAT 0 estiverem corretas.
-
Se o roteamento estiver correto e o tráfego atingir fora da interface, que passa para dentro, o exemplo de saída mostra que a descriptografia está completa, mas a criptografia não ocorre.
-
Se o comando sysopt permit connection-vpn estiver configurado no ASA. Se não estiver configurado, configure esse comando, pois ele isenta o tráfego criptografado/VPN para o ASA da verificação de ACL da interface.
Configurar o par de backup para o túnel VPN no mesmo mapa de criptografia
Problema
Você quer usar múltiplos peers de backup para um único túnel vpn.
Solução
A configuração de vários pares é equivalente ao provisionamento de uma lista de fallback. Para cada túnel, a ferramenta de segurança tenta negociar com o primeiro peer da lista. Se esse peer não responde, a ferramenta de segurança continua nos outros peers até que um peer responda ou até não houver mais peers na lista. O ASA tem um mapa de criptografia já configurado como o par primário. O peer secundário pode ser adicionado após o principal. Este exemplo de configuração mostra o peer principal como X.X.X.X e o peer de backup como o Y.Y.Y.Y:
ASA(config)#crypto map mymap 10 set peer X.X.X.X Y.Y.Y.Y
Desabilite/Reinicie o Túnel VPN
Problema
Para desativar temporariamente o túnel VPN e reiniciar o serviço, conclua o procedimento descrito nesta seção.
Solução
Execute o comando crypto map interface no modo de configuração global para remover um mapa de criptografia definido anteriormente definido para uma interface. Execute a forma deste comando para remover o conjunto de mapas de criptografia da interface.
hostname(config)#no crypto map map-name interface interface-name
Esse comando remove um mapa de criptografia definido para qualquer interface de dispositivo de segurança ativa e altera o túnel VPN IPsec para inativo na interface. Para reiniciar o túnel de IPsec em uma interface, você deve atribuir um mapa de criptografia ajustado a uma relação antes que a relação possa fornecer serviços IPSec.
hostname(config)#crypto map map-name interface interface-name
Alguns Túneis não Criptografados
Problema
Quando um número enorme de túneis são configurado no gateway de VPN, alguns túneis não irão passar tráfego. O ASA não recebe pacotes criptografado para aqueles túneis.
Solução
Este problema ocorre porque o ASA não passa pacotes criptografado através dos túneis. As regras de criptografia duplicadas são criadas na tabela ASP.
Erro:- %ASA-5-713904: Grupo = DefaultRAGroup, IP = x.x.x.x, ... versão v2 do Modo de Transação sem suporte.Túnel encerrado
Problema
O %ASA-5-713904: Group = DefaultRAGroup, IP = 192.0.2.0,... unsupported Transaction Mode v2 version.Tunnel terminatederror é exibida.
Solução
O motivo para a mensagem de erro do Modo de transação v2 é que o ASA oferece suporte apenas à configuração do modo IKE v6 e não à versão antiga do modo v2. Use IKE Mode Config v6 para resolver este erro.
Erro:- %ASA-6-722036: Group client-group User xxxx IP x.x.x.x que transmitem o pacotes maiores 1220 (ponto inicial 1206)
Problema
O %ASA-6-722036: Group < client-group > User < xxxx > IP < x.x.x.x> Transmite pacotes maiores 1220 (ponto inicial 1206) mensagens de erro aparece nos registros do ASA. Que este registro significa e como isto podem ser resolvido?
Solução
Essa mensagem de log informa que um pacote grande foi enviado ao cliente. A origem do pacote não estava ciente do MTU do cliente. Isso pode ocorrer devido à compactação de dados não compactáveis. Você pode desativar a compactação SVC com o comando thesvc compression none, que resolve o problema.
Mensagem de erro quando o QoS está habilitado em uma extremidade do túnel VPN
Problema
Se você habilitou o QoS em uma extremidade do túnel VPN, você pode receber esta mensagem de erro:
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 check
Solução
Essa mensagem normalmente é causada quando uma extremidade do túnel executa a QoS. Isso acontece quando um pacote é detectado como fora de ordem. Você pode desabilitar a QoS para interromper isso, mas ela pode ser ignorada, desde que o tráfego possa passar pelo túnel.
AVISO: Entrada do Mapa de Criptografia Incompleta
Problema
Quando você executa o comando crypto map mymap 20 ipsec-isakmp, você pode receber este erro: AVISO: entrada de mapa de criptografia incompleta
Por exemplo:
ciscoasa(config)#crypto map mymap 20 ipsec-isakmp WARNING: crypto map entry incomplete
Solução
Este é um alerta normal quando você define um novo mapa de criptografia; um lembrete de que parâmetros como access-list (match address), transform set e peer address devem ser configurados antes de funcionarem corretamente. Também é padrão ver a primeira linha que você digita para definir o mapa de criptografia e ele não é mostrado na configuração.
Erro:- %ASA-4-400024: IDS:2151 Pacote ICMP Grande da Interface Externa
Problema
Incapaz de passar o grande pacote de ping através do túnel vpn. Quando nós tentamos passar grandes pacotes de ping nós obtemos o erro %ASA-4-400024: Grande pacote ICMP IDS:2151 na interface externa.
Solução
Desative as assinaturas 2150 e 2151 para resolver esse problema. Quando as assinaturas são desativadas, o ping funciona corretamente. Execute estes comandos para desabilitar as assinaturas:
- Desabilitar assinatura 2151 do exame de ASA(config)#ip
- Desabilitar assinatura 2150 do exame de ASA(config)#ip
Erro:- %ASA-4-402119: IPSEC: Pacote de Protocolo (SPI=spi, sequence number= seq_num) Recebido de Remote_IP (nome de usuário) para Local_IP com Falha na Verificação Anti-Replay
Problema
Eu recebi este erro nos mensagens de registro do ASA:
Erro:- %|ASA-4-402119: IPSEC: Um pacote de protocolo (SPI=spi, sequence number= seq_num) foi recebido de remote_IP (nome de usuário) para local_IP e falhou na verificação de antirreprodução.
Solução
Para resolver esse erro, execute o comando crypto ipsec security-association replay window-size para variar o tamanho da janela.
hostname(config)#crypto ipsec security-association replay window-size 1024
A Cisco recomenda que você use o tamanho total da janela 1024 para eliminar qualquer problema de antirreprodução.
Mensagem de Erro - %ASA-4-407001: Negar Tráfego para local-host interface_name:inside_address, Limite de Número de Licenças Excedido
Problema
Poucos hosts não conseguem se conectar à Internet; esta mensagem de erro aparece no syslog: Mensagem de Erro - %ASA-4-407001: Negar o tráfego para o host local interface_name:inside_address, limite de número de licenças excedido
Solução
Esta mensagem de erro é recebida quando o número de usuários excede o limite de usuários para a licença usada. Este erro pode ser resolvido fazendo um upgrade aumentando o número de usuários. A licença de usuário pode incluir 50, 100, ou usuários ilimitados conforme necessário.
Mensagem de Erro - %VPN_HW-4-PACKET_ERROR:
Problema
A mensagem de erro - %VPN_HW-4-PACKET_ERROR: indica que o pacote ESP com HMAC recebido pelo roteador não corresponde. Esse erro pode ser causado por estes problemas:
-
Módulo VPN H/W defeituoso
-
Pacote ESP corrompido
Solução
Para resolver essa mensagem de erro:
-
Ignore os Mensagens de Erro a menos que haja rompimento de tráfego.
-
Se houver rompimento de tráfego, substitua o módulo.
Mensagem de Erro: Comando rejeitado: Exclua a conexão criptografada entre VLAN XXXX e XXXX, primeiro
Problema
Este Mensagem de Erro aparece quando você tenta adicionar um VLAN permitida na porta tronco de um interruptor: Comando rejeitado: exclua primeiro a conexão criptografada entre a VLAN XXXX e a VLAN XXXX. O tronco de borda da WAN não pode ser modificado para permitir VLANs adicionais. Se você não puder adicionar VLANs no tronco VPN SPAdo IPSEC. Esse comando é rejeitado porque resulta em uma VLAN de interface conectada criptografada que pertence à lista de VLANs permitidas, o que representa uma possível violação de segurança do IPSec.
Note: Esse comportamento se aplica a todas as portas de tronco.
Solução
Em vez do comando no switchport trunk allowed vlan (vlanlist), execute o comando switchport trunk allows vlan noneou o comando "switchport trunk allowed vlan remove (vlanlist)".
Mensagem de Erro - % FW-3-RESPONDER_WND_SCALE_INI_NO_SCALE: Pacote Ignorado - Opção de Escala de Janela Inválida para Sessão x.x.x.x:27331 a x.x.x.x:23 [Iniciador (flag 0,fator 0) Respondente (flag 1, fator 2)]
Problema
Este erro ocorre quando você tenta a telnet de um dispositivo na ponta oposta de um túnel VPN ou quando você tenta a telnet do próprio roteador: Mensagem de erro - % FW-3-RESPONDER_WND_SCALE_INI+NO_SCALE: Pacote descartado - Opção inválida de escala de janela para a sessão x.x.x.x:27331 a x.x.x.x:23 pediaK[Initiator(flag 0,fator 0) Responder (flag 1, fator 2)]
Solução
A licença de usuário pode incluir 50, 100, ou usuários ilimitados conforme necessário. A função de escala de janela foi adicionada para permitir a rápida transmissão de dados em redes longas (LFN). Essas são normalmente conexões com alta largura de banda e alta latência. As redes com conexões via satélite são um exemplo de LFN, já que os links via satélite sempre têm atrasos de propagação altos com largura de banda tipicamente alta. Para ativar a função de escala de janela para suportar LFNs, o tamanho da janela TCP deve ser superior a 65.535. Esta mensagem de erro poderá ser resolvida se você aumentar o tamanho da janela TCP para mais de 65.535.
%ASA-5-305013: Regras assimétricas NAT se combinam para avante e para trás. Favor Atualizar o fluxo deste problema
Problema
Esta Mensagem de Erro aparece uma vez que o túnel VPN surge: %ASA-5-305013: As regras de NAT assimétrico correspondem a encaminhamento e reversão. Favor Atualizar o fluxo deste problema.
Solução
Para resolver esse problema quando não estiver na mesma interface que o host com NAT, use o endereço mapeado em vez do endereço real para se conectar ao host. Além disso, ative o comando inspect se a aplicação incorporar o endereço IP.
%ASA-5-713068: Mensagem de notificação recebida fora da rotina: notify_type
Problema
Este Mensagem de Erro aparece se o túnel VPN não aparece: %ASA-5-713068: Mensagem de notificação recebida fora da rotina: notify_type
Solução
Esta mensagem ocorre devido a erros de configuração (quando as políticas ou ACLs não são configuradas da mesma forma nos pares). Quando as políticas e ACLs são correspondidas, o túnel é ativado sem qualquer problema.
%ASA-5-720012: ((VPN-Secundário) Falha na atualização do tempo de execução do IPSec na unidade em espera (ou) %ASA-6-720012: ((VPN-unidade) Falha na atualização do tempo de execução de dados na unidade em espera
Problema
Uma destas mensagens de erro é exibida quando você tenta atualizar o Cisco Adaptive Security Appliance (ASA):
- %ASA-5-720012: (VPN-Secundário) Falha na atualização do tempo de execução do failover do IPSec na unidade em espera.
- %ASA-6-720012: (VPN-unidade) Falha na atualização do tempo de execução do failover do IPsec na unidade em espera.
Solução
Essas mensagens de erro são erros informativos e não afetam a funcionalidade do ASA ou da VPN. Eles aparecem quando o subsistema de failover de VPN não pode atualizar dados de tempo de execução relacionados ao IPsec porque o túnel IPsec relacionado foi excluído na unidade em espera. Para resolver isso, execute o comando thewr standby na unidade ativa.
Erro:- %ASA-3-713063: Endereço de peer IKE não configurado para o destino 0.0.0.0
Problema
O %ASA-3-713063: A mensagem de erro IKE Peer address not configured for destination 0.0.0.0 é exibida e o túnel não é exibido.
Solução
Esta mensagem aparece quando o endereço de peer IKE não está configurado para um túnel L2L. O erro pode ser resolvido se você alterar o número de sequência do mapa de criptografia e, em seguida, remover e reaplicar o mapa de criptografia.
Erro: %ASA-3-752006: Falha do Gerenciador de Túnel ao Despachar uma Mensagem KEY_ACQUIRE
Problema
O %ASA-3-752006: O Gerenciador de túnel falhou ao enviar a mensagem KEY_ACQUIRE. Configuração incorreta provável do mapa de criptografia ou do grupo de túneis. mensagem de erro está registrada no log do ASA.
Solução
Essa mensagem de erro pode ter sido causada pela configuração incorreta do mapa de criptografia ou do grupo de túneis. Verifique se ambos estão configurados corretamente. Para obter mais informações sobre essa mensagem de erro, consulte 752006 de erro.
Abaixo, seguem algumas soluções corretivas:
-
Remova a ACL criptografada associada ao mapa dinâmico.
-
Se existirem, remova as configurações de IKEv2 não utilizadas.
-
Verifique se a ACL criptografada corresponde corretamente.
-
Remova todas as entradas duplicadas da lista de acesso.
Erro: %ASA-4-402116: IPSEC: Recebido um Pacote ESP (SPI= 0x99554D4E, número de sequência= 0x9E) de XX.XX.XX.XX (user= XX.XX.XX.XX) para YY.YY.YY.YY
Em uma configuração de túnel VPN de LAN a LAN, a seguinte mensagem de erro é recebida no ASA de uma das extremidades:
O pacote interno desencapsulado não corresponde à política negociada na SA.
O pacote especifica o destino como 10.32.77.67, a origem como 10.105.30.1 e o protocolo como icmp.
O SA especifica seu proxy local como 10.32.77.67/255.255.255.255/ip/0 e seu remote_proxy como 10.105.42.192/255.255.255.224/ip/0.
Solução
Você deve verificar as listas de acesso de tráfego exclusivas definidas em ambas as extremidades do túnel VPN. Ambos devem corresponder como imagens espelhadas exatas.
Falha para iniciar o intalador 64-bit VA para habilitar o adaptador virtual devido ao erro 0xffffffff
Problema
A Falha para lançar o 64-bit VA installer para habilitar o adaptador vitrual devido ao erro erro 0xffffffff mensagem de registro recebida quando o Any Connect falha para se conectar.
Solução
Conclua estas etapas para resolver esse problema:
-
Vá paraSistema > Gerenciamento de Comunicação da Internet > Configurações de Comunicação da Internet e assegure-se de que Desativar Certificados Raiz Automáticos Atualizações esteja desabilitada.
-
Se estiver desabilitado, desabilite a parte inteiraAdministrative Template do GPO atribuído ao computador afetado e teste novamente. Consulte Desativar Certificados Raiz Automáticos Atualizar para obter mais informações.
O Cisco VPN Client não funciona com o cartão de dados no Windows 7
Problema
O Cisco VPN Client não funciona com o cartão de dados no Windows 7.
Solução
O Cisco VPN Client instalado no Windows 7 não funciona com conexões 3G, pois não há suporte para cartões de dados em clientes VPN instalados em máquinas com Windows 7.
Alerta: "A “funcionalidade de VPN pode não funcionar”
Problema
Durante as tentativas de ativar o isakamp na interface externa do ASA, esta mensagem de alerta será recebida:
ASA(config)# crypto isakmp enable outside WARNING, system is running low on memory. Performance may start to degrade. VPN functionality may not work at all.
O acesso ao ASA por meio de SSH e HTTPS é interrompido e outros clientes SSL também são afetados.
Solução
Este problema é causado pelos requisitos de memória dos diferentes módulos tais como o registador e a criptografia. Certifique-se de que você não tenha o comando logging queue 0. Isso faz com que o tamanho da fila seja definido como 8192 e a alocação de memória aumente. Em plataformas como o ASA5505 e o ASA5510, essa alocação de memória tende a esgotar a memória de outros módulos.
Erro no preenchimento do IPSec
Problema
A seguinte mensagem de erro é recebida:
%ASA-3-402130: CRYPTO: Received an ESP packet (SPI = 0xXXXXXXX, sequence number= 0xXXXX) from x.x.x.x (user= user) to y.y.y.y with incorrect IPsec padding
Solução
O problema ocorre porque a VPN IPSec negocia sem um algoritmo de hash. O hash de pacotes garante a verificação de integridade do canal ESP. Portanto, sem hash, os pacotes malformados são aceitos e não são detectados pelo Cisco ASA e ele tenta descriptografá-los. No entanto, como esses pacotes estão malformados, o ASA encontra falhas durante a descriptografia de pacotes. Isso provoca as mensagens de erro no preenchimento verificadas. A recomendação é incluir um algoritmo de hash no conjunto de transformação para a VPN e garantir que o link entre os peers tenha um mínimo de malformação de pacote.
O túnel VPN é desconectado a cada 18 horas
Problema
O túnel VPN é desconectado a cada 18 horas, mesmo que o tempo de vida esteja definido para 24 horas.
Solução
O tempo de vida é o tempo máximo que a AS pode ser usada para uma rechave. O valor configurado para o tempo de vida é diferente do tempo de rechaveamento da associação de segurança. É necessário negociar um novo SA (ou par SA no caso de IPsec) antes que o atual expire. O tempo de rechaveamento deve ser menor que o tempo de vida para permitir várias tentativas caso a primeira tentativa de rechaveamento falhe.
Os RFCs não especificam como calcular o tempo de nova chave. Isso é deixado a seu critério, portanto, o tempo varia com a plataforma. Algumas implementações usam um fator aleatório para calcular o tempo de rechaveamento. Por exemplo, se o ASA iniciar o túnel, é normal que ele faça uma nova chave em 64800 segundos = 75% do 86400. Se o roteador iniciar, o ASA poderá esperar mais para fornecer ao peer mais tempo para iniciar a nova chave. Portanto, é normal que a sessão VPN seja desconectada a cada 18 horas para usar outra chave para a negociação VPN.
O fluxo de tráfego não é mantido depois que o túnel de LAN para LAN é renegociado
Problema
O fluxo de tráfego não é mantido após a renegociação do túnel de LAN a LAN.
Solução
O ASA monitora cada conexão que passa e mantém uma entrada em sua tabela de estados de acordo com o recurso de inspeção de aplicativos. Os detalhes do tráfego criptografado que passam pela VPN são mantidos na forma de um banco de dados de associação de segurança (SA). Para as conexões VPN de LAN a LAN, ele mantém dois fluxos de tráfego diferentes. Um é o tráfego criptografado entre os gateways VPN. O outro é o fluxo de tráfego entre o recurso de rede do gateway de VPN e o usuário final da outra extremidade.
Quando a VPN é encerrada, os detalhes do fluxo dessa SA específica são excluídos. Contudo, a entrada na tabela de estados mantida pelo ASA para essa conexão TCP torna-se obsoleta por inatividade, o que dificulta o download. Isso significa que o ASA ainda retém a conexão TCP para esse fluxo específico enquanto a aplicação do usuário é encerrada. As conexões TCP se tornam perdidas e, por fim, atingem o tempo limite depois que o temporizador de ociosidade TCP expira. Esse problema foi resolvido ao implementar um recurso chamado Fluxos persistentes com túnel IPSec. Um novo comando, sysopt connection preserve-vpn-flows, foi integrado ao Cisco ASA para reter as informações da tabela de estados na renegociação do túnel VPN.
Por padrão, esse comando está desativado. Para ativar esse recurso, o Cisco ASA mantém as informações da tabela de estados do TCP quando a VPN L2L se recupera da interrupção e restabelece o túnel.
A mensagem de erro indica que a largura de banda recorreu à funcionalidade de criptografia
Problema
O roteador 2900 Series recebeu a seguinte mensagem de erro:
Erro: 20 de março, 10:51:29: %CERM-4-TX_BW_LIMIT: O limite máximo de largura de banda Tx de 8500 Kbps foi atingido para a funcionalidade Crypto com a licença do pacote de tecnologia securityk9.
Solução
Esse é um problema já conhecido que ocorre devido às rígidas diretrizes impostas pelo Governo dos Estados Unidos da América. De acordo com a licença securityk9, ela só pode permitir uma criptografia de payload até taxas próximas a 90 Mbps e limita o número de túneis criptografados/sessões TLS para o dispositivo. Para obter mais informações sobre restrições de exportação de criptografia, consulte Cisco ISR G2 SEC e Licenciamento HSEC.
Para dispositivos Cisco, é derivado para ser menos de 85 Mbps de tráfego unidirecional de entrada ou saída do roteador ISR G2 com um total bidirecional de 170 Mbps. Esse requisito aplica-se às plataformas ISR G2 Cisco 1900, 2900 e 3900. Este comando ajuda a visualizar estas limitações:
Router#show platform cerm-information Crypto Export Restrictions Manager(CERM) Information: CERM functionality: ENABLED ---------------------------------------------------------------- Resource Maximum Limit Available ---------------------------------------------------------------- Tx Bandwidth(in kbps) 85000 85000 Rx Bandwidth(in kbps) 85000 85000 Number of tunnels 225 225 Number of TLS sessions 1000 1000 ---Output truncated----
Para evitar esse problema, compre uma licença HSECK9. Uma licença de recurso "hseck9" fornece funcionalidade de criptografia de payload aprimorada com maior número de túneis VPN e sessões de voz seguras. Para obter mais informações sobre o licenciamento do roteador Cisco ISR, consulte Ativação de software.
Problema: O tráfego de criptografia de saída no túnel IPsec falha, mesmo que o tráfego de descriptografia de entrada funcione
Solução
Esse problema foi observado em uma conexão IPsec após várias rechaves, no entanto, a condição do acionador não está clara. A presença desse problema pode ser estabelecida se você verificar a saída do comando show asp drop e verificar se o contador de contexto VPN expirado aumenta para cada pacote de saída enviado.
Diversos
A mensagem AG_INIT_EXCH aparece em “mostrar criptografia isakmp sa” e nos Comandos de Saída “debug"
Se o túnel não for iniciado, a mensagem AG_INIT_EXCHaparece na saída do comando show crypto isakmp sae na saída debugtambém. O motivo pode estar relacionado a uma incompatibilidade de políticas de ISAKMP ou se a porta udp 500 estiver bloqueada.
Debugar a mensagem “Você recebeu um mensagem IPC durante o estado inválido” aparece
Esta mensagem é um mensagem informativa e não não tem relação com a desconexão do túnel VPN.
Informações Relacionadas
- ASA e Cisco IOS®: Fragmentação VPN
- Ferramentas de segurança do Cisco ASA 5500 Series
- Negociação IPsec/Protocolos IKE
- Suporte Técnico e Documentação - Cisco Systems
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
2.0 |
22-Jul-2026
|
Ortografia, gramática e linhas horizontais inseridas atualizadas em seções separadas para facilitar a leitura e alertas fixos do CCW. |
1.0 |
31-Mar-2014
|
Versão inicial |
Feedback