Problème de tunnel VPN

VPN
1

Je remarque un problème étrange avec un tunnel VPN entre mon ASA et le ISR d’un fournisseur. Le tunnel se monte mais je ne vois que des décapsulations et pas d’encapsulations. Tout semble correct dans la configuration entre nous. Des suggestions seraient les bienvenues.

ASA5516X# show crypto ikev2 sa

SAs IKEv2:

Session-id:8, Statut:UP-ACTIVE, nombre d’IKE:1, nombre d’ENFANT:1

ID tunnel : 565556617 x.x.x.x/500 a0
Localisation :a0 x.x.x.x/500 a0
Remote : x.x.x.x/500 a0
Statut : PReAt a0Role : RESPONDER

Chiffrement : AES-CBC, taille de la cle9 : 256, Hash : SHA512, Groupe DH : 2, Auth sign : PSK, Auth verify : PSK

Vie / Temps actif : 86400/140 sec

Child sa : se9lecteur local 10.144.32.23/0 - 10.144.32.23/65535

se9lecteur distant x.x.x.x/0 - x.x.x.x/65535

ESP spi entrant / sortant : 0x78a7b38a/0xb077e2b0a0

ASA5516X# sh crypto ipsec sa

#pkts encaps : 0, #pkts encrypt : 0, #pkts digest : 0
#pkts decaps : 19, #pkts decrypt : 19, #pkts verify : 19
#pkts compression : 0, #pkts decompression : 0
#pkts non compressa0: 0, #pkts echec compression : 0, #pkts echec decompression : 0
#pre9-frag succe8s : 0, #pre9-frage9 failures : 0, #fragments cre9e9s : 0
#PMTUs envoye9s : 0, #PMTUs ree7us : 0, #frags de9se9s pour re9assemblage : 0
#TFC ree7us : 0, #TFC envoye9s : 0
#Erreurs ICMP valides ree7ues : 0, #Erreurs ICMP invalides ree7ues : 0
#erreurs envoi : 0, #erreurs re9ception : 0

packet-tracer input inside_144 tcp 10.144.32.17 45678 x.x.x.x 443 details

Phase : 1
Type : RECHERCHE-ITINERAIRE
Sous-type : Reconnaissance du point de sortie
Re9sultat : PERMET
Configuration :
Informations additionnelles :
Trouve9 le prochain saut x.x.x.x en utilisant l’interface de sortie Outside-BT

Phase : 2
Type : NON-NAT
Sous-type : statique
Re9sultat : PERMET
Configuration :
NAT (inside_144,Outside-BT) source statique IP_Cameras IP_Cameras destination statique FarsightHost1 FarsightHost1 no-proxy-arp route-lookup
Informations additionnelles :
NAT redirige9 vers l’interface de sortie Outside-BT
Non traduit x.x.x.x/443 en x.x.x.x/443

Phase : 3
Type : LISTE-D’ACCc8S
Sous-type : journal
Re9sultat : PERMET
Configuration :
groupe d’accès inside_access_in en interface inside_144
Liste d’accès inside_access_in autorise extension objet Standard_Web_Out tout le monde
Objet-Group service Web standard
service-objet tcp destination e9q www
service-objet tcp destination e9q https
Informations additionnelles :
Recherche base9e sur le flux de transfert :
Dans id=0x7fcc8038d9d0, priorite9=13, domaine=permettre, deny=false
hits=68, user_data=0x2aaacdf4b9c0, cs_id=0x0, use_real_addr, flags=0x0, protocole=6
src ip/id=10.144.0.0, masque=255.255.0.0, port=0, e9tiquette=any
dst ip/id=0.0.0.0, masque=0.0.0.0, port=443, e9tiquette=any, dscp=0x0
input_ifc=inside_144, output_ifc=any

Phase : 4
Type : PARAMc9TRc8S-Connexions
Sous-type :
Re9sultat : PERMET
Configuration :
class-map SFR-REDIRECT
match access-list global_mpc_1
policy-map global_policy
class SFR-REDIRECT
set connection decrement-ttl
service-policy global_policy global
Informations additionnelles :
Recherche base9e sur le flux de transfert :
Dans id=0x7fcc805b0780, priorite9=7, domaine=politique-connexion, deny=false
hits=1177721, user_data=0x2aaada1a8560, cs_id=0x0, use_real_addr, flags=0x0, protocole=0
src ip/id=0.0.0.0, masque=0.0.0.0, port=0, e9tiquette=any
dst ip/id=0.0.0.0, masque=0.0.0.0, port=0, e9tiquette=any, dscp=0x0
input_ifc=inside_144, output_ifc=any

Phase : 5
Type : NAT
Sous-type :
Re9sultat : PERMET
Configuration :
nat (inside_144,Outside-BT) source static IP_Cameras IP_Cameras destination static FarsightHost1 FarsightHost1 no-proxy-arp route-lookup
Informations additionnelles :
Traduction statique 10.144.32.17/45678 en 10.144.32.17/45678
Recherche base9e sur le flux de transfert :
Dans id=0x7fcc80d582b0, priorite9=6, domaine=nat, deny=false
hits=11, user_data=0x7fcc787a1ee0, cs_id=0x0, flags=0x0, protocole=0
src ip/id=10.144.32.17, masque=255.255.255.255, port=0, e9tiquette=any
dst ip/id=x.x.x.x, masque=255.255.255.255, port=0, e9tiquette=any, dscp=0x0
input_ifc=inside_144, output_ifc=Outside-BT

Phase : 6
Type : NAT
Sous-type : session par session
Re9sultat : PERMET
Configuration :
Informations additionnelles :
Recherche base9e sur le flux de transfert :
Dans id=0x2aaad924d170, priorite9=0, domaine=nat-per-session, deny=false
hits=52502245, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocole=6
src ip/id=0.0.0.0, masque=0.0.0.0, port=0, e9tiquette=any
dst ip/id=0.0.0.0, masque=0.0.0.0, port=0, e9tiquette=any, dscp=0x0
input_ifc=any, output_ifc=any

Phase : 7
Type : OPTIONS-IP
Sous-type :
Re9sultat : PERMET
Configuration :
Informations additionnelles :
Recherche base9e sur le flux de transfert :
Dans id=0x7fcc803173a0, priorite9=0, domaine=inspect-ip-options, deny=true
hits=124051384, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocole=0
src ip/id=0.0.0.0, masque=0.0.0.0, port=0, e9tiquette=any
dst ip/id=0.0.0.0, masque=0.0.0.0, port=0, e9tiquette=any, dscp=0x0
input_ifc=inside_144, output_ifc=any

Phase : 8
Type : SFR
Sous-type :
Re9sultat : PERMET
Configuration :
class-map SFR-REDIRECT
match access-list global_mpc_1
policy-map global_policy
class SFR-REDIRECT
sfr fail-open
service-policy global_policy global
Informations additionnelles :
Recherche base9e sur le flux de transfert :
Dans id=0x7fcc7810cde0, priorite9=71, domaine=sfr, deny=false
hits=625854, user_data=0x7fcc80318360, cs_id=0x0, use_real_addr, flags=0x0, protocole=0
src ip/id=0.0.0.0, masque=0.0.0.0, port=0, e9tiquette=any
dst ip/id=0.0.0.0, masque=0.0.0.0, port=0, e9tiquette=any, dscp=0x0
input_ifc=inside_144, output_ifc=any

Phase : 9
Type : FOVER
Sous-type : mise e0 jour de veille
Re9sultat : PERMET
Configuration :
Informations additionnelles :
Recherche base9e sur le flux de transfert :
Dans id=0x7fcc8031d0d0, priorite9=20, domaine=lu, deny=false
hits=59705, user_data=0x0, cs_id=0x0, flags=0x0, protocole=6
src ip/id=0.0.0.0, masque=0.0.0.0, port=0, e9tiquette=any
dst ip/id=0.0.0.0, masque=0.0.0.0, port=0, e9tiquette=any, dscp=0x0
input_ifc=inside_144, output_ifc=any

Phase : 10
Type : EXPORTATION-DE-FLUX
Sous-type :
Re9sultat : PERMET
Configuration :
Informations additionnelles :
Recherche base9e sur le flux de transfert :
Dans id=0x7fcc80365960, priorite9=18, domaine=exportation-de-flux, deny=false
hits=19680671, user_data=0x2aaada2f9f10, cs_id=0x0, use_real_addr, flags=0x0, protocole=0
src ip/id=0.0.0.0, masque=0.0.0.0, port=0, e9tiquette=any
dst ip/id=0.0.0.0, masque=0.0.0.0, port=0, e9tiquette=any, dscp=0x0
input_ifc=inside_144, output_ifc=any

Phase : 11
Type : VPN
Sous-type : chiffrement
Re9sultat : REFUSe9
Configuration :
Informations additionnelles :
Recherche base9e sur le flux de transfert :
Sortie id=0x7fcc80e0c5d0, priorite9=70, domaine=chiffrement, deny=false
hits=12, user_data=0x0, cs_id=0x2aaad9acc100, inverse, flags=0x0, protocole=0
src ip/id=10.144.32.17, masque=255.255.255.255, port=0, e9tiquette=any
dst ip/id=x.x.x.x, masque=255.255.255.255, port=0, e9tiquette=any, dscp=0x0
input_ifc=any, output_ifc=Outside-BT

Re9sultat :
interface d’entrée : inside_144
statut d’entrée : actif
statut de la ligne d’entrée : actif
interface de sortie : Outside-BT
statut de sortie : actif
statut de la ligne de sortie : actif
Action : rejeter
Raison du rejet : (acl-drop) Le flux est refuse9 par la re8gle configure9e

2

Vérifiez votre ACL de phase 2. Elle est rejete9e e0 le9tape de chiffrement VPN et l’adresse IP source ne correspond pas au SA de9fini. Faitesa0leur aussi vérifier de leur cf4te9.

3

En ignorant toutes les autres informations donnent ci-dessus, il semble que vous ne puissiez ne9gocier qu’une seule association de se9curite9 avec le pair. Comme vous eates le re9pondeur, pas l’initiateur, je serais curieux de voir ce qui se passe si vous re9initialisez les SA du tunnel puis essayez d’utiliser packet tracer pour devenir l’initiateur avec cette IP. Si vous constatez que votre SA se negocie correctement pour cette IP, mais que d’autres IP ne peuvent pas construire de SA alors vous avez votre re9ponse et il serait préférable de autoriser un re9seau (/24 par exemple) et d’utiliser un filtre VPN.

a0

Si tout est pareil, c’est la seule chose que je peux penser qui causerait le comportement vu ci-dessus. J’ai aussi vu des bugs incroyables sur la plateforme ASA et ISR, donc peut-eatre que https://quickview.cloudapps.cisco.com/quickview/bug/CSCue42170 peut vous aider e0 mieux comprendre si c’est un bogue ou si la the9orie de la seule SA est la cause.

4

L’ACL correspond e0 ce qui est configure9, elle correspond aussi e0 l’ACL que le fournisseur m’a envoye9e de leur cf4te9.

5

Il veut dire l’ACL de crypto-mapping.

La crypto-mapping semble eatre configure9e pour autoriser une seule IP, 10.144.32.23. Mais le trafic dans packet tracer provient de 10.144.32.17.

Si cette IP est correcte alors vous devez modifier votre ACL crypto pour inclure .17, sinon vous avez fait une faute de frappe dans votre commande packet tracer.

6

Pouvez-vous publier votre ACL de filtre VPN ?

J’ai vu un bug auparavant of9 le trafic est rejete9 sur une ACL de filtre VPN inexistante. La solution e9tait d’en ajouter une avec tout ou rien, ou de rede9marrer ou d’utiliser le failover si en haute disponible.

7

De9sole9, j’ai mal lu, voici l’ACL de cryptomapping

access-list FarsightPri_ACL extended permit ip object-group IP_Cameras host 194.0.239.23

object-group network IP_Cameras

network-object host 10.144.32.17

network-object host 10.144.32.18

network-object host 10.144.32.22

network-object host 10.144.32.23

network-object host 10.144.32.240

network-object host 10.144.32.241

8

Bien, pas de problème, voici ma configuration côté.

access-list FarsightVPN1-Filter extended permit ip host 194.239.23, object-group IP_Cameras

object-group network IP_Cameras
network-object host 10.144.32.17
network-object host 10.144.32.18
network-object host 10.144.32.22
network-object host 10.144.32.23
network-object host 10.144.32.240
network-object host 10.144.32.241

`

Voici la configuration côté fournisseur.

ip access-list extended MSAS
permit ip host 194.239.23, host 10.144.32.17
permit ip host 194.239.23, host 10.144.32.18
permit ip host 194.239.23, host 10.144.32.22
permit ip host 194.239.23, host 10.144.32.23
permit ip host 194.239.23, host 10.144.32.240
permit ip host 194.239.23, host 10.144.32.241

9

La ligne 10.144.32.17 a-t-elle été ajoutée récemment ?

10

peux-tu confirmer que tes IP sont des IP privées d’un côté et que l’IP publique provient du fournisseur ? et que la règle de ton côté devrait être le groupe d’objets IP_Cameras puis l’hôte (l’IP du fournisseur). Peux-tu m’envoyer la configuration VPN sur les deux côtés ?

11

Non, c’était déjà en place, le problème est survenu lorsque le fournisseur a changé leur appareil peer et aussi est passé d’IKEv1 à IKEv2. Donc après avoir reconstruit la Phase 1 et 2, voici ce qui se passe. Je n’ai jamais touché aux ACL, elles sont restées telles qu’elles étaient avant.

12

Oui, de mon côté, j’ai les IP privés et le fournisseur possède une seule IP publique.

13

Si le fournisseur a changé leur côté et que ça a cassé… pourquoi regardes-tu encore ça ? C’est clairement quelque chose qu’ils ont foutu en l’air. Très probablement, ils ont mal configuré leur crypto map ou ont tenté de faire un résumé, et tu ne reçois pas de SA pour cette IP.

14

dans ce cas, tu dois changer l’ordre des adresses IP dans ta liste d’accès.

15

Oui, je suis d’accord, mais ils sont passés de IKEv1 à IKEv2, donc nous avons essayé de reconstruire le tunnel, c’est pourquoi j’ai posté ici. Ma suggestion était de revenir à la configuration précédente lorsque cela fonctionnait.

16

IKEv2 est ce que tu devrais utiliser, alors autant, change aussi le groupe DH 2 en 14 ou plus.

Je leur demanderais de t’envoyer leur configuration P2. Je parie qu’il y a une faute de frappe ou quelque chose qui manque.

17

Je laisserais en IKEv2, et pendant que tu y es, change aussi le groupe DH 2 par quelque chose de bien meilleur, comme 14 ou 21.

Je leur demanderais de t’envoyer leurs réglages P2 et de t’assurer qu’ils correspondent aux tiens, parce que je pense que ce n’est pas le cas.

Aussi, personnellement, c’est configuré à l’envers de ma méthode habituelle. Tu as des P2 individuels par hôte mais l’ACL autorise le /16.

Je tends à faire le cryptomap large, et faire le filtrage précis dans l’ACL. Parce qu’ainsi, tu ne dois pas toucher aux paramètres du tunnel à chaque fois qu’un autre hôte doit accéder. Cela minimise le risque de rupture.

Je ferais que la crypto map autorise juste 10.144.0.0/16 vers 194.0.239.23.

Puis, utiliser le VPN-filter pour le restreindre aux hôtes spécifiques.

En fait… je n’aime pas du tout utiliser les filtres VPN, parce qu’ils sont liés au tunnel et les changements n’ont d’effet qu’à la réinitialisation du tunnel, ce qui est agaçant. Je préfère utiliser un VTI et appliquer des ACLs sur l’interface VTI.

C’est juste ma façon de faire, chacun ses préférences. Mais j’ai passé le meilleur de mes 15 ans à gérer le problème de l’ASA Cisco et j’ai appris quelques astuces pour gagner du temps.

18

Merci pour l’info, très apprécié!