Description

This article is about bypassing the IKE-ID validation from ID payload.

Symptoms

During IKE Phase 1 negotiation, when SRX receives negotiation request, there are two identity checks.

1. IKE-ID validation from ID payload
2. Phase 1 authentication by pre-shared key or RSA/DSA certificate

For information about Phase 1 authentication by pre-shared key or RSA/DSA certificate, please refer to:
http://www.juniper.net/techpubs/en_US/junos-srx/topics/concept/vpn-security-phase-1-ike-proposal-understanding.html

IKE-ID validation from ID payload and another is phase 1 authentication, preshared key or RSA/DSA certificates.
For IKE-ID validation, configured remote-identity ( set security ike gateway <gateway> remote-identity  <remote-identity> ) or default remote-identity will be used.

Configured remote-identity would also be used to lookup the certificate of the peer for certificate authentication.
The remote-identity used should match the corresponding field in the SubjectAltname extension of the peer's certificate for successful detection of peer's certificate and consequent peer authentication.

Since identity check with the same IKE-ID will be done twice, IKE-ID validation with remote-identity first and then certificate authentication, SRX has an option to bypass the first IKE-ID validation with remote-identity.

Solution


When general-ikeid is set, SRX will bypass IKE-ID validation with received ID Payload.

- set security ike gateway <gateway_name> general-ikeid

This will allow to bypass extra processes on matching IKE-ID validation and certificate authentication.

The general-ike-id feature works on following conditions:
- Both main and aggressive mode
- LAN-to-LAN IPSec (*1)
- Certificate Authentication (*2)
- IKE v1/v2

(*1) For dial-up, received IKE-ID check is a must.
(*2) general-ikeid for pre-shared-key is supported from 11.4R5.

Related Information