VPN El túnel falla con "Error en la negociación secundaria SA de IKEv2 al procesar el selector de tráfico". - Los proxy IDno son espejos exactos entre sí

VPN El túnel falla con "Error en la negociación secundaria SA de IKEv2 al procesar el selector de tráfico". - Los proxy IDno son espejos exactos entre sí

62054
Created On 08/02/22 22:23 PM - Last Modified 05/09/23 06:00 AM


Symptom


  • VPN El túnel no subió o bajó
  • Registros del sistema que muestran "mensaje de notificación de protocolo recibido: tipo de notificación recibida TS_UNACCEPTABLE"IKE
  • Registros del sistema que muestran "Error en la negociación secundaria SA de IKEv2 al procesar el selector de tráfico. no se puede encontrar el túnel IPSec coincidente para el selector de tráfico recibido".
  • CLI mostrar resultados de comandos en los dos firewalls del mismo nivel muestran que las entradas de proxy ID no son un reflejo exacto entre sí
  • > menos MP-log ikemgr.log mostrando "ts inaceptable"
  • >menos MP-log ikemgr.log mostrando " resultado coincidente: TS_l desajuste (!=), TS_r desajuste (!=)"TS
  • >menos MP-log ikemgr.log mostrando " 0: error de coincidencia:"TS
  • Este problema de proxy no será visible en una captura de paquetes (a menos que pcap se descifre manualmente), por lo que es mejor usar CLI comandos / verificar manualmente las configuraciones de ambos lados para identificar y resolver cualquier entrada de proxy ID ID incorrecta.

Telaraña UI
Vaya a Túneles IPSec de red > > edite la pestaña
Comparación de proxy IDno reflejados entre VPN pares en la Web UI
ID de proxy > túnel IPSec Recuerde, los ID de proxy anteriores son incorrectos porque coinciden. Los ID de proxy deben ser espejos exactos entre sí (es decir, ser opuestos), no coincidir

con los ID de proxy correctos para un túnel Ejemplo: 1: 192.168.10.0/24 > 192.168.20.0/24 2: 192.168.20.0/24 > 192.168.10.0/24 ID de proxy

incorrectos para un ejemplo de túnel: 1: 192.168.10.0/24 > 192.168.20.0/24 2:
VPN Firewall
VPN Firewall 192.168.10.0/24 > 192.168.20.0/24
VPN Firewall
VPN Firewall

¿Qué es un ID

CLI
VPN VPN proxy y cuándo se necesita? En ambos VPN pares, ejecute los siguientes comandos a través de  CLI
> 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


Registros del sistema
Vaya a Supervisar > registros del sistema


Wireshark Tome una captura de paquetes en ambos VPN pares y ábralos en Wireshark en paralelo Nota: Esto no aparecerá en
Mostrando Wireshark para ID de proxy Fase 2
Mostrando Wireshark para ID de proxy Fase 2 2
Wireshark
de forma predeterminada. Debe tener registros ikemgr de nivel de volcado de ambos VPN pares para descifrar los paquetes en Wireshark. Esto se puede hacer usando los pasos aquí

ikemgr.log
Ejecute el siguiente comando a través CLI de en ambos pares

A continuación se muestran los registros de ikemgr cuando se configura un proxy que coincide con el VPN proxy ID ID del par que envían, lo que significa que es incorrecto. Recuerde que los proxy IDno deben coincidir, sino que deben ser espejos exactos entre sí. 


>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

Nota: Recuerde, la declaración != significa "no es igual a"

Environment


  • PAN-OS
  • Palo Alto Networks firewall configurado con IPSec VPN Tunnel específicamente con un par basado en -en lugar de un Policypar basado en VPN VPN Routed (es decir, se utiliza ACL para controlar VPN el tráfico, no las rutas)
  • Si su par es un par basado en ruta, no es necesario usar ningún ID de proxy (debe dejarse en blanco), simplemente configure las rutas utilizando el túnel.X interfaz en VPN su VPN lugar

Cause


Este problema ocurre cuando no se encuentra una entrada de proxy en el par, que es un espejo exacto de la entrada de proxy en nuestra firewall

Práctica recomendada, es hacer que cada entrada de proxy en nuestro firewall tenga una entrada de proxy ID ID ID ID correspondiente en el par firewall que es un espejo perfecto (es decir, firewall un espejo)ACL

Resolution


  1. Vuelva a configurar ambos VPN pares, asegurándose de que todas ID y cada una de las entradas de proxy individuales tengan una entrada de proxy ID espejo exacta en el par (es decir, asegúrese de VPN que sean ACL opuestas)

Ejemplo:
Comparar las buenas prácticas de trabajo de los ID de proxy que son un espejo perfecto entre sí en la Web UI
(En el ejemplo anterior, se usaron dos firewalls de Palo Alto Networks como VPN pares. Si su par es un proveedor firewalldiferente, realice su cambio de configuración de proxy ID equivalente / mismo (generalmente conocido como selector de tráfico o criptoACL) en su firewall VPN si son la causa raíz de la no duplicación)
  1. Realizar una confirmación
  2. Ejecute los siguientes comandos un par de veces cada uno en ambas CLI del VPN mismo nivel firewall para que se inicien y formen recientemente:
>clear vpn ike-sa gateway <name>
>clear vpn ipsec-sa tunnel <name>


Other users also viewed:
Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000wlDmCAI&lang=es&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language