VPN Le tunnel échoue avec « La négociation enfant SA IKEv2 a échoué lors du traitement du sélecteur de trafic ». - Les proxys IDne sont pas des miroirs exacts les uns des autres

• VPN Le tunnel ne monte pas ou ne descend pas
• Journaux système affichant «IKE message de notification de protocole reçu : type de notification reçue TS_UNACCEPTABLE »
• Journaux système affichant « Échec de la négociation enfant SA IKEv2 lors du traitement du sélecteur de trafic. impossible de trouver le tunnel IPSec correspondant pour le sélecteur de trafic reçu.
• CLI afficher les sorties de commandes sur les deux pare-feu homologues montrent que les entrées Proxy ID ne sont pas un miroir exact l’une de l’autre
• >moins mp-log ikemgr.log montrant « ts inacceptable »
• >moins mp-log ikemgr.log affichant "TS matching result: TS_l mismatch(!=), TS_r mismatch(!=) »
• >moins mp-log ikemgr.log montrant "TS 0: match fail: »
• Ce problème de proxy ne sera pas visible dans une capture de paquets (sauf si pcap est déchiffré manuellement), il est donc préférable d'utiliser CLI simplement les commandes / vérifier manuellement les configurations des deux côtés pour identifier et résoudre les entrées de proxy ID ID incorrectes

> show vpn flow tunnel-id 2

tunnel  VPNTunnel10:Send-192-168-10-0-thruTunnel
        id:                     2
        type:                   IPSec
        gateway id:             1
        local ip:               203.0.113.200
        peer ip:                203.0.113.100
        inner interface:        tunnel.10
        outer interface:        ethernet1/1
        proxy-id:
          local ip:             192.168.10.0/24
          remote ip:            192.168.20.0/24

> show vpn tunnel
TnID                Name                         Gateway          Local Proxy IP       Ptl:Port   Remote Proxy IP      Ptl:Port   Proposals
2  VPNTunnel10:Send-192-168-10-0-thruTunnel  IKEGatewayTest1      192.168.10.0/24      0:0        192.168.20.0/24      0:0

Journaux système
Accédez à Surveiller > journaux système


Wireshark Prenez une capture de paquets sur les deux pairs et ouvrez-les VPN côte à côte


dans Wireshark Remarque: Cela n’apparaîtra pas dans Wireshark
par défaut. Vous devez disposer de journaux ikemgr au niveau du vidage des deux VPN pairs pour déchiffrer les paquets dans Wireshark. Cela peut être fait en utilisant les étapes ici

ikemgr.log
Exécutez la commande ci-dessous via CLI sur les deux pairs

Vous trouverez ci-dessous les journaux ikemgr lorsqu'un proxy est configuré qui correspond au proxy ID ID de lVPN'homologue qu'ils envoient, ce qui signifie qu'il est incorrect. Rappelez-vous que les proxy IDne doivent pas correspondre - au lieu de cela, ils doivent être des miroirs exacts les uns des autres.

>less mp-log ikemgr.log

18:42:40 [INFO]: remote
18:42:40 [INFO]: TS Payload: type=TS_IPV4_ADDR_RANGE proto=0 length=16 start_port=0 end_port=65535
18:42:40 [INFO]: TS Starting Address=192.168.10.0
18:42:40 [INFO]: TS Ending Address=192.168.10.255
18:42:40 [INFO]: TS payload dump:
18:42:40 [INFO]: local
18:42:40 [INFO]: TS Payload: type=TS_IPV4_ADDR_RANGE proto=0 length=16 start_port=0 end_port=65535
18:42:40 [INFO]: TS Starting Address=192.168.20.0
18:42:40 [INFO]: TS Ending Address=192.168.20.255
18:42:40 [INFO]: local
18:42:40 [INFO]: TS Payload: type=TS_IPV4_ADDR_RANGE proto=0 length=16 start_port=0 end_port=65535
18:42:40 [INFO]: TS Starting Address=192.168.20.0
18:42:40 [INFO]: TS Ending Address=192.168.20.255
18:42:40 [INFO]: remote
18:42:40 [INFO]: TS Payload: type=TS_IPV4_ADDR_RANGE proto=0 length=16 start_port=0 end_port=65535
18:42:40 [INFO]: TS Starting Address=192.168.10.0
18:42:40 [INFO]: TS Ending Address=192.168.10.255
18:42:40 [DEBG]: TS matching for configured selector VPNTunnel10:Send-192-168-20-0-thruTunnel 192.168.10.0[0]/24-192.168.
20.0[0]/24 proto 0
18:42:40 [DUMP]: num_ts 1
18:42:40 [DEBG]: .. check local TS (num 1, TS0 is not specific) against selector 0:192.168.10.0[0]/24
18:42:40 [DUMP]: checking TS 0
18:42:40 [DEBG]: {     :    2}: ... TS 0: match fail: 192.168.20.0->192.168.20.255(ts) vs. 192.168.10.0->192.168.10.255(selector)
18:42:40 [DEBG]: ... result: local TS != 192.168.10.0[0]/24
18:42:40 [DUMP]: num_ts 1
18:42:40 [DEBG]: .. check remote TS (num 1, TS0 is not specific) against selector 0:192.168.20.0[0]/24
18:42:40 [DUMP]: checking TS 0
18:42:40 [DEBG]: {     :    2}: ... TS 0: match fail: 192.168.10.0->192.168.10.255(ts) vs. 192.168.20.0->192.168.20.255(selector)
18:42:40 [DEBG]: ... result: remote TS != 192.168.20.0[0]/24
18:42:40 [DEBG]: TS matching result: TS_l mismatch(!=), TS_r mismatch(!=)
18:42:40 [PERR]: ts unacceptable

Note: Rappelez-vous, l’énoncé != signifie « n’est pas égal à »

• PAN-OS
• Réseaux firewall Palo Alto configurés avec le tunnel IPSec VPN spécifiquement avec un homologue basé VPN sur -au lieu d’un Policyhomologue basé sur VPN le routage (c’est-à-dire utilisé ACL pour contrôler VPN le trafic, pas les itinéraires)
• Si votre VPN homologue est un homologue basé sur VPN un itinéraire, il n’est pas nécessaire d’utiliser des ID de proxy (à laisser vide) - configurez simplement les itinéraires à l’aide du tunnel.X interface à la place

1. Reconfigurez les deux VPN homologues, en vous assurant que chaque entrée de ID proxy individuelle a une entrée proxy ID miroir exacte sur l’homologue (c’est-à-dire assurez-vous qu’elles VPN sont opposées aux ACL)

2. Effectuer une validation
3. Exécutez les commandes ci-dessous plusieurs fois chacune sur les deux CLI homologues firewall pour les initier et les VPN former :

>clear vpn ike-sa gateway <name>
>clear vpn ipsec-sa tunnel <name>