Why Does IKEv1 IPsec Tunnel Show 'Proxy Identities Not Supported'?

350-701 By islever Editorial Last updated

Short answer

D Ensure that the IPsec ACLs defining interesting traffic mirror each other (reversible entries) on both VPN peers.

Question

Refer to the exhibit. An administrator is configuring a VPN tunnel on a Cisco router. The information provided by the administrator of the remote end of the VPN tunnel was that IKEv1 is the tunnel protocol with a preshared key of C1$c0463835440!. The encryption for both phases is AES and the hash for both phases is SHA-256. The source subnet is 10.10.10.x/24 and the destination subnet is 10.10.20.x/24. The local device cannot establish a VPN tunnel and the debug message shown here is seen in the log file. What must be verified to correct the configuration? - Exhibit: Why Does IKEv1 IPsec Tunnel Show 'Proxy Identities Not Supported'?
  1. Ensure that the IKE version is identical on both ends
  2. Ensure that the ISAKMP policy configuration is identical on both ends
  3. Ensure that the preshared key is identical on both ends
  4. Ensure that the ACLs that define interesting traffic are symmetrical on both ends Correct Answer

Key Takeaways

Recognizing the specific IPsec/ISAKMP debug text and mapping it to an ACL asymmetry, not to phase 1 IKE or preshared-key mismatches, is the tested skill.

The Cisco debug 'proxy identities not supported' means the IPsec traffic-selector ACLs on the two peers do not reverse each other, so the tunnel fails even when IKEv1, AES, SHA-256, and the preshared key are correctly configured. This 350-701 page establishes that the correct configuration check is D, with official Cisco debug references and community consensus.

Common mistake: The most common wrong pick is C, assuming the preshared key C1$c0463835440! is mismatched, but a PSK error produces a different ISAKMP authentication failure rather than the proxy-identity debug.

Expert Analysis

Why the Answer Is Correct

The debug line "proxy identities not supported" is emitted by IPsec validation when the local and remote traffic selectors (the ACLs defining interesting traffic) do not match as reversible entries. In the exhibit, the local subnet 10.10.10.x/24 and remote 10.10.20.x/24 must appear in mirror-image ACLs on both peers, so each side's source/destination pair equals the other side's destination/source. With IKEv1, phase 2 quick mode selects the proxy identities from those ACLs; if one side permits 10.10.20.0/24 -> 10.10.10.0/24 and the other permits something asymmetric, the proposal is invalidated and the tunnel never comes up. Therefore D is correct: verify that the ACLs are symmetrical. The preshared key and IKE version were explicitly supplied by the remote administrator and are not what this particular debug points to.

Why the Other Options Are Wrong

A is wrong because an IKE version mismatch produces different debug output, typically ISAKMP policy or SA establishment failures, not "proxy identities not supported." B is wrong because differing ISAKMP policies cause phase 1 proposal rejections about encryption, hash, or authentication mismatches. C is wrong because a wrong preshared key generates messages about preshared-key authentication failure, not a proxy-identity validation error. Only D matches the specific exhibit: the debug is Cisco's signal that the access lists do not mirror each other.

Community Comment Notes

Multiple learners cited Cisco's IPsec debug documentation: 97c291d quoted "Proxy Identities Not Supported" and explained that "The access lists on each peer need to mirror each other." nm1122 reached the same conclusion, linking Cisco's 5409-ipsec-debug document and repeating the reversible-entry requirement, while dfb0b7d added the same proxy-identity explanation. A lone commenter, klu16, leaned toward B but offered no analysis, and the vote tally reflects strong community agreement on D. That consensus aligns with the Cisco debug text rather than with IKE or PSK troubleshooting paths.

Official Reference

https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/5409-ipsec-debug-00.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

Memorize the exact debug string "proxy identities not supported" and associate it with asymmetric IPsec ACLs; Cisco exams often use this wording to separate ACL issues from IKE or PSK errors. When the scenario already gives matching IKEv1, AES, SHA-256, and PSK details, focus on the traffic-selector ACLs first.

Frequently Asked Questions

Why does the debug say 'proxy identities not supported' when the ACLs mismatch?

Cisco's IPsec debug emits that message when the traffic selectors from the ACLs are not reversible between peers, so the phase 2 proposal is invalidated.

Would an IKEv1 or preshared key mismatch produce the same debug?

No; those typically show phase 1 negotiation or authentication failures, while 'proxy identities not supported' specifically flags mismatched interesting-traffic ACLs.

More 350-701 FAQ →

Community Votes

D
100%

100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 5 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 5

  1. 97c291d 👍 4 Answered D
    Proxy Identities Not Supported This message appears in debugs if the access list for IPsec traffic does not match. 1d00h: IPSec(validate_transform_proposal): proxy identities not supported 1d00h: ISAKMP: IPSec policy invalidated proposal 1d00h: ISAKMP (0:2): SA not acceptable! The access lists on each peer need to mirror each other (all entries need to be reversible). This example illustrates this point. Peer A access-list 150 permit ip 172.21.113.0 0.0.0.255 172.21.114.0 0.0.0.255 access-list 150 permit ip host 10.2.0.8 host 172.21.114.123 Peer B access-list 150 permit ip 172.21.114.0 0.0.0.255 172.21.113.0 0.0.0.255 access-list 150 permit ip host 172.21.114.123 host 10.2.0.8 Source: https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/5409-ipsec-debug-00.html
  2. nm1122 👍 2 Answered D
    https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/5409-ipsec-debug-00.html#toc-hId-1987608815 The access lists on each peer need to mirror each other (all entries need to be reversible). This example illustrates this point. Peer A access-list 150 permit ip 172.21.113.0 0.0.0.255 172.21.114.0 0.0.0.255 access-list 150 permit ip host 10.2.0.8 host 172.21.114.123 Peer B access-list 150 permit ip 172.21.114.0 0.0.0.255 172.21.113.0 0.0.0.255 access-list 150 permit ip host 172.21.114.123 host 10.2.0.8
  3. dfb0b7d 👍 2 Answered D
    Proxy Identities Not Supported This message appears in debugs if the access list for IPsec traffic does not match. The access lists on each peer need to mirror each other (all entries need to be reversible). https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/5409-ipsec-debug-00.html
  4. klu16 👍 1 Answered B
    I think I will go with B here...
  5. kloug 👍 1
    The answer is a

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

What Is a Feature of an Endpoint Detection and Response Solution?

S-grade

Which Two Methods Belong in an AAA Authentication Method List?

S-grade

Preventing Unauthorized DHCP Servers on Cisco Switches

S-grade

What Is Considered a Cloud Data Breach in Cisco 350-701?

S-grade

← Back to 350-701 Study Guide