Why Does a Cisco IPsec VPN 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 Insight
The exam tests whether you can distinguish a phase-1 ISAKMP proposal mismatch from an IPsec proxy-identity/ACL mismatch; the trap is treating every 'proposal invalidated' line as an ISAKMP policy problem.
This Cisco IPsec troubleshooting question examines a failed IKEv1 tunnel whose debug shows 'proxy identities not supported' and establishes that the interesting-traffic ACLs must be symmetrical (D).
Most learners pick B because the debug includes 'IPSec policy invalidated proposal' and 'SA not acceptable,' but those are downstream symptoms; the specific 'proxy identities not supported' line points to non-mirrored interesting-traffic ACLs.
Community Discussion (10 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The decisive debug line is "proxy identities not supported," followed by "IPSec policy invalidated proposal" and "SA not acceptable"; in Cisco IPsec debugs this sequence indicates that the peers' interesting-traffic ACLs do not describe mirrored, reversible proxy identities, not that the preshared key or phase-1 policy is necessarily wrong. The administrator was told the source subnet is 10.10.10.x/24 and the destination is 10.10.20.x/24, so the local ACL must permit 10.10.10.0/24 to 10.10.20.0/24 while the remote ACL must permit 10.10.20.0/24 back to 10.10.10.0/24, with matching wildcard masks and any host entries reversed. Because option D explicitly asks to verify that the ACLs defining interesting traffic are symmetrical, it is the action that directly resolves the proxy-identity rejection. The PSK, IKE version, and identical ISAKMP policy still matter for a healthy tunnel, but they are not what this particular debug signature identifies.Why the Other Options Are Wrong
Option B is the strongest distractor because "IPSec policy invalidated proposal" and "SA not acceptable" can appear when phase-1 ISAKMP parameters differ, but those lines are downstream effects here; the preceding "proxy identities not supported" narrows the fault to the ACL/proxy-ID comparison. Option A would matter if one peer were IKEv1 and the other IKEv2, which typically yields version or notify errors rather than a proxy identity complaint, and the prompt already states IKEv1 is used. Option C is tempting because a wrong preshared key causes phase-1 authentication failure, but the debug would normally show hash validation or pre-shared key authentication failure, not "proxy identities not supported." The question gives the PSK as C1$c0463835440! and does not show an authentication-failure debug, so verify ACL symmetry first.Community Comment Notes
Several learners point to Cisco's "Understand and Use Debug Commands to Troubleshoot IPsec" document, quoting the line "proxy identities not supported" and explaining that the ACLs on each peer must mirror each other. dfb0b7d and 97c291d both emphasize that every ACL entry needs to be reversible, which matches the 10.10.10.0/24-to-10.10.20.0/24 subnet pair in the prompt. A minority, including klu16 and Makate, focuses on the ISAKMP policy as option B because the debug also shows a rejected proposal; that is a reasonable but less precise reading of the full debug sequence. The weight of the cited Cisco documentation and the explicit "proxy identities" wording supports D.Official Reference
Exam Strategy
When an IPsec debug includes both a proposal rejection and a proxy-identity message, read the line immediately before the proposal rejection before choosing a phase-1 policy answer. In this question, the proxy-identity wording is the specific fingerprint for asymmetric interesting-traffic ACLs, so verify mirror-image ACL entries on both peers first.
Frequently Asked Questions
Why does 'proxy identities not supported' point to ACLs instead of the preshared key?
Cisco treats the source/destination subnets in each peer's crypto ACL as proxy identities; if 10.10.10.0/24-to-10.10.20.0/24 is not mirrored, phase 2 rejects the proposal even with a matching PSK.
Can a phase-1 ISAKMP policy mismatch also cause 'SA not acceptable'?
Yes, a phase-1 mismatch can produce proposal-invalidated or SA-not-acceptable messages, but the decisive 'proxy identities not supported' line here is tied to asymmetric IPsec ACLs.