Contest #1 : IPSEC Troubleshooting – 1
Voilà, chose promise, chose due.
Ci joint un fichier dynagen, j’ai laissé l’idlepc et l’image IOS, libre à vous de remplacer ces valeurs par n’importe quelle autre routeur de la famille, le plus important étant la ligne configuration=, qui contient, vous l’aurez deviné, la configuration problématique.
Pour faire simple, vous avez deux routeurs reliés entre eux par le réseau 1.1.1.0/30, chacun de ces routeurs ayant des loopback simulant un LAN.
Le but ici est de pouvoir pinger :
R1#ping ip 192.168.2.1 source 192.168.1.1
doit fonctionner (inverser les IP sur l’autre routeur).
R1 loop 0: 192.168.1.1/24
R2 loop 0: 192.168.2.1/24
Petit indice: debug crypto ipsec
Le fichier.net:
Edit: Bien joué à IGOR pour la avoir trouvé la solution, l’erreur était bien au niveau de la crypto ACL, il faut matcher le trafic au niveau de la source ET de la destination!
dans le debug crypto IPSEC, l’on peut voir:
*Mar 1 00:01:32.175: IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) INBOUND
local= 1.1.1.2,
remote= 1.1.1.1,
local_proxy= 192.168.2.0/255.255.255.0/0/0 (type=4), remote_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4), protocol= ESP,
transform= esp-des esp-md5-hmac (Tunnel), lifedur= 0s and 0kb, spi= 0×0(0), conn_id= 0, keysize= 0, flags= 0×0
*Mar 1 00:01:32.183: Crypto mapdb : proxy_match
src addr : 192.168.2.0
dst addr : 0.0.0.0
protocol : 0
src port : 0
dst port : 0
*Mar 1 00:01:32.195: IPSEC(crypto_ipsec_process_proposal): proxy identities not supported
Notez le dst addr : 0.0.0.0
Si je redéfinis l’access list comme ceci:
R1(config)#ip access-list extended TUNNEL R1(config-ext-nacl)#no 10 R1(config-ext-nacl)#permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
et vice versa, j’obtiens:
*Mar 1 00:01:28.056: Crypto mapdb : proxy_match
src addr : 192.168.2.0
dst addr : 192.168.1.0
protocol : 0
src port : 0
dst port : 0
*Mar 1 00:01:28.064: IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 1.1.1.1
*Mar 1 00:01:28.068: IPSEC(policy_db_add_ident): src 192.168.2.0, dest 192.168.1.0, dest_port 0
*Mar 1 00:01:28.072: IPSEC(create_sa): sa created, (sa) sa_dest= 1.1.1.2, sa_proto= 50,
et le ping passe!
Recent Entries
- Reponse tardive aux commentaires
- CCIE #43827
- VRF-Aware GETVPN, DMVPN, et FLEXVPN Spoke To Spoke
- Mes articles sur supportforums
- Définir des « handlers » personnalisés pour associer les liens d’un protocole avec une application perso.
- DMVPN over GETVPN avec KS COOP (redondance) et KS Forwarding
- EAP-TLS avec Autorité de certification autonome (Standalone CA) sous Windows 2003
- Static subnet NAT avec VRF pour monter des ‘PODs’ (LAB)
- Capture WiFi en mode monitor sous windows, et capture par process
- Comment taper un point d’interrogation ‘?’ dans un mot de passe ?
octobre 12th, 2009 at 6:37
Interesting traffic is incorrectly defined. Redefining extended access-list TUNNEL is the solution.
Also for people like me that are using GNS3, use any base64 decoder (like http://www.opinionatedgeek.com/dotnet/tools/Base64Decode/) to get configuration from dynagen .net file. Just copy paste string value of configuration for each router.
octobre 12th, 2009 at 11:42
Good game IGOR, you’re right. I’ve updated the post (in french), so feel free to ask if you don’t understand something.