VPN Der Tunnel schlägt mit der Meldung "IKEv2 Child SA Negotiation Failed when Processing Traffic Selector" fehl. - Proxys IDsind keine exakten Spiegel zueinander

• VPN Tunnel kam nicht hoch oder ging runter
• Systemprotokolle, die " Protokollbenachrichtigung empfangen: empfangene Benachrichtigung Typ TS_UNACCEPTABLE"IKE anzeigen
• Systemprotokolle, die zeigen, dass die untergeordnete SA IKEv2-Aushandlung bei der Verarbeitung der Datenverkehrsauswahl fehlgeschlagen ist. Es kann kein passender IPSec-Tunnel für den Selektor für den empfangenen Datenverkehr gefunden werden.
• CLI show-Befehlsausgaben auf den beiden Peer-Firewalls zeigen, dass die Proxy-Einträge ID nicht exakt gespiegelt werden
• >weniger mp-log ikemgr.log zeigt "ts inacceptable" an
• >weniger mp-log ikemgr.log zeigt "TS übereinstimmendes Ergebnis: TS_l mismatch(!=), TS_r mismatch(!=)"
• >weniger mp-log ikemgr.log zeigt " 0: Match Fail:"TS
• Dieses Proxy-Problem ID ist in einer Paketerfassung nicht sichtbar (es sei denn, pcap wird manuell entschlüsselt), daher ist es am besten, nur Befehle zu verwenden CLI / die Konfigurationen beider Seiten manuell zu überprüfen, um falsche Proxy-Einträge ID zu identifizieren und zu beheben

> 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

Systemprotokolle
Navigieren Sie zu Überwachen > Systemprotokolle


Wireshark Nehmen Sie eine Paketerfassung auf beiden VPN Peers vor und öffnen Sie sie in Wireshark nebeneinander


Hinweis: Dies wird standardmäßig nicht in Wireshark
angezeigt. Sie müssen über ikemgr-Protokolle auf Dump-Ebene von beiden VPN Peers verfügen, um die Pakete in Wireshark zu entschlüsseln. Dies kann mit den folgenden Schritten hier erfolgen: ikemgr.log
Führen Sie den folgenden Befehl

über CLI auf beiden Peers aus

Im Folgenden sind die ikemgr-Protokolle aufgeführt, wenn ein Proxy konfiguriert ist, der mit dem VPN von ihm gesendeten Proxy ID ID des Peers übereinstimmt, was bedeutet, dass er falsch ist. Denken Sie daran, dass die Proxys IDnichtübereinstimmen sollten - stattdessen sollten sie exakte Spiegelvoneinander sein 

>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

Hinweis: Denken Sie daran, dass die Aussage != "ist nicht gleich" bedeutet

• PAN-OS
• Palo Alto Networks firewall , die mit IPSec-Tunnel VPN speziell mit einem Policy-basierten VPN Peer anstelle eines gerouteten VPN Peers konfiguriert sind (d. h. zur ACL Steuerung VPN des Datenverkehrs, nicht von Routen)
• Wenn es sich bei Ihrem VPN Peer um einen routenbasierten VPN Peer handelt, müssen Sie keine Proxy-IDs verwenden (sollten leer gelassen werden) - konfigurieren Sie einfach Routen über den Tunnel.X Schnittstelle

1. Konfigurieren Sie beide VPN Peers neu und stellen Sie sicher, dass jeder einzelne Proxy-Eintrag einen exakten Spiegel-Proxy-Eintrag ID auf dem VPN Peer hat (d. h. stellen Sie sicher, dass es sich um entgegengesetzte ACLs handelt). ID

2. Ausführen eines Commits
3. Führen Sie die folgenden Befehle jeweils einige Male auf beiden VPN Peer-CLIs firewall aus, damit sie neu initiiert und gebildet werden:

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