VMware ESXi and vSphere Cluster Management

iSCSI CHAP Authentication Overview for VMware ESXi

Learn how one-way and mutual iSCSI CHAP authentication work in VMware ESXi, including credential scope, configuration planning, validation, and troubleshooting.

CHAP is the Challenge Handshake Authentication Protocol, an authentication method used while an iSCSI session is being established. It helps an iSCSI target verify that a connecting ESXi initiator is authorized, and mutual CHAP can also help the initiator verify the target.

This lesson covers one-way and mutual CHAP, shared secrets, adapter-level and per-target configuration, operational planning, and troubleshooting.

iSCSI Roles and the Purpose of CHAP

iSCSI transports SCSI storage commands over an IP network. The two important endpoints are the initiator and the target.

  • Initiator: The client endpoint that starts an iSCSI session. In this context, it is usually an ESXi host or its iSCSI adapter.
  • Target: The storage endpoint that provides iSCSI logical units, commonly called LUNs, to authorized initiators.

CHAP participates in session login. Depending on the selected mode, the target confirms the identity of the initiator, or both endpoints confirm each other before storage access is granted.

CHAP is authentication, not encryption. It helps prove identity during login, but it does not encrypt iSCSI commands or storage data in transit. Storage networks still require appropriate segmentation, access control, and—where confidentiality is required—an encryption solution.

How CHAP Authentication Works

CHAP uses a challenge-response exchange. A challenge is a value issued during authentication. The endpoint responding to the challenge uses a configured shared secret to calculate a response. The secret itself is not sent directly across the network.

  1. One endpoint requests authentication and supplies a challenge value.
  2. The other endpoint combines the challenge with the shared secret and calculates a hash-derived response.
  3. The receiving endpoint calculates or verifies the expected response.
  4. If the response matches, that authentication direction succeeds; otherwise, the login is rejected.

This exchange is commonly described as a three-way handshake: challenge, response, and verification. Its purpose is to prove knowledge of a reusable secret without transmitting that secret as a plaintext password during the login exchange.

A hash value is a derived value used in the exchange. It is not the secret itself. However, CHAP does not make poor secrets safe: weak or reused secrets remain a security risk.

One-Way CHAP

One-way CHAP, also called unidirectional CHAP, authenticates the initiator to the target only.

  • The storage target challenges the ESXi initiator.
  • The ESXi initiator proves knowledge of the configured initiator CHAP secret.
  • The target decides whether to permit the iSCSI login.
  • The ESXi initiator does not verify the target's identity in this mode.

The required values normally include an initiator CHAP name or identifier and an initiator CHAP secret. Names may be displayed as usernames, CHAP names, or identifiers depending on the ESXi and storage-array interfaces.

One-way CHAP is useful when the primary requirement is restricting which hosts can log in to a target. For example, a storage administrator can create an access entry for an ESXi initiator and configure the matching one-way credentials on both systems.

Mutual CHAP

Mutual CHAP, also called bidirectional CHAP, authenticates both endpoints.

  • The target authenticates the ESXi initiator.
  • The ESXi initiator authenticates the target.
  • Both authentication exchanges must succeed before the session is established.

Mutual authentication reduces the risk that an ESXi host connects to an unauthorized or impersonated target. It is preferable when storage-access security requirements are stronger or when target identity must be verified as well as initiator identity.

Mutual CHAP requires separate credentials for the two directions. The initiator credential is used by the target to validate the initiator. The target credential is used by the initiator to validate the target. Use different secrets for these directions; do not reuse one secret for both roles.

Authentication mode: One-way CHAP

Who authenticates the initiator: Target

Who authenticates the target: Neither endpoint in CHAP

Credential requirements: Initiator CHAP name and initiator secret

Security characteristics: Restricts initiator logins but does not verify target identity

Typical use case: Environments primarily needing host-to-target access restriction

Authentication mode: Mutual CHAP

Who authenticates the initiator: Target

Who authenticates the target: Initiator

Credential requirements: Separate initiator and target names and secrets

Security characteristics: Authenticates both endpoints; use distinct secrets

Typical use case: Production environments with stronger storage-access requirements

CHAP Support and Configuration Scope in ESXi

CHAP is disabled by default unless an administrator enables and configures it. The exact screens and supported options depend on the ESXi release and the iSCSI initiator type.

Adapter-Level CHAP

Adapter-level CHAP applies credentials to an iSCSI adapter. A common initiator credential can therefore be presented to all targets accessed through that adapter.

  • It is useful when several targets use a common initiator identity and credential policy.
  • It simplifies administration because one adapter setting can cover multiple target relationships.
  • It can provide less isolation when targets require different credentials or belong to separate security zones.

Per-Target CHAP

Per-target CHAP assigns credentials individually to a particular target. This can provide better isolation between storage targets, tenants, or security zones. A credential rotation or exposure can be limited to one target relationship instead of affecting every target using the adapter.

Per-target CHAP is supported for software iSCSI initiators and dependent hardware iSCSI initiators. Verify the initiator type and the documentation for the exact ESXi version before relying on a particular credential scope or override behavior.

Configuration scope: Adapter-level

Applies to: Targets accessed through the selected adapter

Credential behavior: Common initiator credentials are generally presented to those targets

Supported initiator types: Depends on ESXi release and adapter implementation

Advantages: Centralized and simpler administration

Limitations: Less isolation between targets; target-specific requirements may not fit

Configuration scope: Per-target

Applies to: One specified iSCSI target

Credential behavior: Target-specific credentials can override or supplement broader settings where supported

Supported initiator types: Software iSCSI and dependent hardware iSCSI initiators

Advantages: Better isolation and more targeted credential rotation

Limitations: More administration and version- or initiator-dependent support

Credential Planning and Secret Management

Interfaces may use different labels for the same concepts. A CHAP name, username, or identifier identifies the authenticating party; a secret is the confidential value used to calculate authentication responses. Confirm the meaning of each field in both the ESXi and storage-array interfaces before entering values.

  • Plan unique credentials for separate hosts, adapters, targets, or security zones where the platform supports that design.
  • Use different secrets for initiator-to-target and target-to-initiator authentication in mutual CHAP.
  • Choose sufficiently strong, unpredictable secrets that satisfy the storage platform's length and character requirements.
  • Store secrets in an approved administrative credential-management process.
  • Document which host, adapter, target, and direction each credential belongs to.
  • Coordinate changes on ESXi and the storage target. Updating only one endpoint can interrupt discovery or active sessions.

Configuration Workflow

  1. Confirm network reachability. Verify that the ESXi VMkernel iSCSI interfaces can reach the target portals. Check VLANs, routing, firewall rules, MTU expectations, and any required port binding before changing authentication.
  2. Enable the intended initiator. Enable or identify the software iSCSI initiator or hardware iSCSI adapter that will access the target.
  3. Select the authentication design. Choose disabled, one-way CHAP, or mutual CHAP according to the security requirement and target capabilities.
  4. Configure the storage target. Create or update the ESXi initiator access entry, select the same CHAP mode, enter matching initiator credentials, and configure target credentials for mutual CHAP if required.
  5. Configure ESXi. Enter the matching initiator name and secret. For mutual CHAP, enter the separate target name and target secret. Apply the values at adapter scope or per-target scope as appropriate.
  6. Confirm non-CHAP authorization. Verify target portal access, initiator authorization, LUN presentation, and access-control or masking rules independently of CHAP.
  7. Rescan storage. After applying the settings, rescan the storage adapters so ESXi can rediscover targets, sessions, paths, and devices.
  8. Validate service state. Confirm target discovery, successful session login, expected device and path visibility, datastore availability, and multipath status.
  9. Document the result. Record credential ownership, target-to-host mappings, scope, change time, and rollback steps.

Operational and Security Considerations

CHAP protects session authentication but does not replace dedicated storage networking, VLAN isolation, routing restrictions, firewall policy, LUN masking, or other access controls. Use these controls together. If storage data must be confidential in transit, evaluate encryption separately.

Changing CHAP settings can terminate active sessions, remove paths, or make datastores temporarily unavailable. Use change control, schedule production work during an appropriate maintenance window, verify redundant paths, and prepare a tested rollback plan.

Multipathing requires special care. Every relevant target path and initiator configuration must use a compatible authentication design. A credential that works on one portal does not prove that every portal, adapter, or target relationship is correctly configured.

Validation and Troubleshooting

Common authentication symptoms include failed target discovery, rejected iSCSI login, unavailable paths, missing devices, or datastores that become inaccessible after a configuration change. Do not assume every storage symptom is a CHAP problem.

First distinguish authentication from basic network, DNS, routing, VLAN, MTU, discovery, target-access, LUN-mapping, and multipathing issues. Verify portal reachability and initiator authorization before changing secrets.

Symptom: Target is discovered but the iSCSI session cannot log in

Likely cause: CHAP enabled on only one endpoint, different CHAP modes, or mismatched initiator name or secret

Verification step: Compare mode and initiator credentials on ESXi and the target

Corrective action: Correct the mismatch, rescan, and confirm the login

Symptom: Mutual CHAP fails after one-way CHAP worked

Likely cause: Missing target credentials, incorrect target name or secret, or reused credentials in both directions

Verification step: Check mutual-CHAP fields separately from initiator fields

Corrective action: Configure the correct identity and distinct secret for each direction

Symptom: Some targets connect but another rejects authentication

Likely cause: Adapter-level credentials are being used where unique target credentials are required, or a per-target override is stale or missing

Verification step: Determine whether the target inherits adapter settings or has a per-target configuration

Corrective action: Configure the correct target-specific values where supported and verify target authorization

Symptom: Authentication appears correct but devices remain unavailable

Likely cause: Network or VMkernel binding issue, target reachability problem, LUN presentation or access-control issue, multipath issue, or missing rescan

Verification step: Check storage networking, target visibility, LUN mapping, path status, and rescan state

Corrective action: Fix the underlying issue, rescan, and inspect device and path status

Evidence to Collect

  • Compare the CHAP mode on both endpoints.
  • Compare initiator CHAP names and secrets.
  • For mutual CHAP, independently verify target names and target secrets.
  • Confirm whether credentials are adapter-level or per-target and whether the initiator type supports the selected scope.
  • Review ESXi storage and iSCSI-related logs together with storage-array authentication and access logs.
  • Check target portal reachability, VMkernel binding, VLAN and routing, MTU, LUN presentation, and multipath configuration.
  • Rescan only after correcting the configuration, then verify restored sessions, paths, devices, and datastores.

Practical Examples

One-Way CHAP for One ESXi Host

An ESXi software iSCSI initiator connects to a SAN target. The storage administrator creates an initiator access entry with a CHAP identity and secret. The VMware administrator configures matching one-way credentials on ESXi. The target permits the login only after the initiator proves knowledge of the shared secret.

Mutual CHAP in Production

The target uses one credential to authenticate the ESXi initiator. ESXi uses a separate target identity and target secret to authenticate the target. Both exchanges succeed before the session is established. Distinct secrets prevent one value from serving both authentication directions.

Adapter-Level and Per-Target Credentials

An ESXi host may use one adapter-level credential for several targets when the storage environment uses a common initiator policy. If targets belong to separate tenants or security zones, per-target credentials, where supported, can isolate those relationships and limit the impact of a credential rotation.

Post-Change Validation

After enabling CHAP on the array and ESXi host, rescan storage. Confirm that expected target sessions are connected, all expected paths appear, devices are visible, and existing datastores remain accessible.

Exam-Relevant Notes

  • CHAP authenticates; it does not encrypt iSCSI traffic.
  • One-way or unidirectional CHAP means the target authenticates the initiator only.
  • Mutual or bidirectional CHAP means both target and initiator authenticate each other.
  • Mutual CHAP uses separate credentials for each direction; do not reuse the same secret.
  • Adapter-level credentials can apply broadly, while per-target credentials provide more granular isolation where supported.
  • A successful CHAP login does not prove that networking, LUN presentation, access control, or multipathing is correct.

For the related configuration topic, see Configuring CHAP authentication on ESXi.