Why Does IKEv1 IPsec Tunnel Show 'Proxy Identities Not Supported'?
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? - 
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
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.
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.
Community Discussion (5 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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
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.