Why Does a Cisco IPsec VPN Tunnel Show Proxy Identities Not Supported?

350-701 By islever Editorial Last updated

Describe site-to-site and remote access VPN deployment types such as virtual tunnel interfaces, standards-based IPsec, SSL VPN, DMVPN, FlexVPN, and GETVPN

Short answer

D Verify that the IPsec interesting-traffic ACLs on both routers mirror each other so the proxy identities match.

Question

Exhibit: 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?
  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

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).

Common mistake: 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.

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

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

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.

More 350-701 FAQ →

Discussion 10 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 10

  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. dfb0b7d 👍 4 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
  3. Makate 👍 4 Answered B
    the debug shows the peer rejected the proposal (IPSec policy invalidated proposal, SA not acceptable, QM rejected), which is the classic sign of a phase-1/ISAKMP parameter mismatch (encryption, hash, DH group, lifetime, etc.). Make the phase-1 ISAKMP policy on both routers identical so the proposal is
  4. nm1122 👍 3 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
  5. XBfoundX 👍 1 Answered D
    as many are mentioning is D period. https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/5409-ipsec-debug-00.html#toc-hId-1987608815 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!
Show 5 more comments
  1. Pages 👍 1 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!
  2. XBfoundX 👍 1
    The document is from the: Understand and Use Debug Commands to Troubleshoot IPsec guide, thank you to everyone that reported the link and the documention retrieved by the link
  3. klu16 👍 1 Answered B
    I think I will go with B here...
  4. kloug 👍 1
    The answer is a
  5. kloug 👍 1
    Answer b

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