An administrator analyzes the following portion of a VPN system log and notices the following issue: Received local id 10.10.1.4/24 type IPv4 address protocol 0 port 0, received remote id 10.1.10.4/24

Question

Options

• AIPSec crypto profile mismatch
• BIPSec protocol mismatch
• Cmismatched Proxy-IDs
• Dbad local and peer identification IP addresses in the IKE gateway

• A
  7% (1)
• B
  7% (1)
• C
  73% (11)
• D
  13% (2)

Explanation

The log message shows the local and remote IDs being exchanged during IPSec Phase 2 (Quick Mode) negotiation. In IPSec VPN, Proxy-IDs define the local and remote subnets (traffic selectors) that each peer expects to encrypt and route through the tunnel. When Proxy-IDs do not match between the two VPN peers - for example, one side defines 10.10.1.0/24 as local while the other expects a different subnet - the Phase 2 negotiation fails. The log output explicitly displaying the received local and remote IDs is the diagnostic signature of a Proxy-ID mismatch, not a crypto profile issue (which would appear in Phase 1 or Phase 2 proposal negotiation), not a protocol mismatch, and not a bad IKE gateway identification address (which would cause Phase 1 to fail before this point).

No community discussion yet for this question.