VPN Tunnel fails with "IKEv2 child SA negotiation failed when processing traffic selector." - Proxy ID's are not exact mirrors of each other
35650
Created On 08/02/22 22:23 PM - Last Modified 08/05/22 20:36 PM
Symptom
- VPN Tunnel not coming up or went down
- System Logs showing "IKE protocol notification message received: received notify type TS_UNACCEPTABLE"
- System Logs showing "IKEv2 child SA negotiation failed when processing traffic selector. cannot find matching IPSec tunnel for received traffic selector."
- CLI show command outputs on the two peer firewalls show that the Proxy ID entries are not an exact mirror of each other
- >less mp-log ikemgr.log showing "ts unacceptable"
- >less mp-log ikemgr.log showing "TS matching result: TS_l mismatch(!=), TS_r mismatch(!=)"
- >less mp-log ikemgr.log showing "TS 0: match fail:"
- This Proxy ID issue won't be visible in a packet capture (unless pcap is manually decrypted), so it is best to just use CLI commands / checking both sides' configurations manually to identify and resolve any incorrect Proxy ID entries
Web UI
Navigate to Network > IPSec Tunnels > edit IPSec Tunnel > Proxy IDs tab
Remember, the Proxy IDs above are incorrect because they match. Proxy IDs should be exact mirrors of each other (i.e. be opposite), not match
Correct Proxy IDs for a VPN tunnel example:
VPN Firewall 1: 192.168.10.0/24 > 192.168.20.0/24
VPN Firewall 2: 192.168.20.0/24 > 192.168.10.0/24
Incorrect Proxy IDs for a VPN tunnel example:
VPN Firewall 1: 192.168.10.0/24 > 192.168.20.0/24
VPN Firewall 2: 192.168.10.0/24 > 192.168.20.0/24
What is a Proxy ID, and when is it needed?
CLI
On both VPN peers, run the below command(s) via 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
System Logs
Navigate to Monitor > System Logs
Wireshark
Take a packet capture on both VPN peers and open them in Wireshark side-by-side
Note: This will not appear in Wireshark by default. You must have dump-level ikemgr logs from both VPN peers to decrypt the packets in Wireshark. This can be done using the steps here
ikemgr.log
Run the below command via CLI on both peers
The below are the ikemgr logs when a Proxy ID is configured that matches the VPN peer's Proxy ID that they send, meaning it is incorrect. Remember the Proxy ID's should not match - instead, they should be exact mirrors of each other
>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: Remember, the statement != means "is not equal to"
Environment
- PAN-OS
- Palo Alto Networks firewall configured with IPSec VPN Tunnel specifically with a Policy-based VPN peer instead of a Routed-based VPN peer (i.e. uses ACL to control VPN traffic, not routes)
- If your VPN peer is a Route-based VPN peer, there is no need to use any Proxy IDs (should be left blank) - simply configure routes using the tunnel.X interface instead
Cause
This issue occurs whenever there is not a Proxy ID entry found on the peer firewall which is an exact mirror of the Proxy ID entry on our firewall
Best Practice is to have each Proxy ID entry on our firewall have a corresponding Proxy ID entry on the peer firewall which is a perfect mirror (i.e. a mirror ACL)
Resolution
- Re-configure both VPN peers, ensuring each and every individual Proxy ID entry has an exact mirror Proxy ID entry on the VPN peer (i.e. ensure they are opposite ACLs)
Example:
(In the example above, two Palo Alto Networks firewalls were used as VPN peers. If your VPN peer is a different vendor firewall, perform their equivalent/same Proxy ID (usually known as Traffic Selector or Crypto ACL) configuration change on their firewall if they are the root cause of the non-mirroring)
- Perform a Commit
- Run the below commands a couple times each on both the VPN peer firewall CLIs to get them to freshly initiate and form:
>clear vpn ike-sa gateway <name> >clear vpn ipsec-sa tunnel <name>