iSCSI Target Authentication Failed – Quick Fix Guide

Quick Answer

Stop what you're doing and check the CHAP username and password on both the initiator and target ends. The culprit is almost always a typo or case mismatch. If you're using mutual CHAP, make sure both sides have the correct credentials for each direction.

Why This Happens

iSCSI uses CHAP (Challenge-Handshake Authentication Protocol) to verify the initiator's identity. When the target rejects login, it's because the initiator presented wrong credentials. But here's the thing – CHAP passwords are case-sensitive and often have special characters. A single wrong character kills the connection. I've seen this exact error on Windows Server 2019, Ubuntu 22.04, and VMware ESXi 7.0 when someone copied a password with a trailing space.

The trigger is almost always after a config change – updating an initiator name, changing passwords on the storage array, or setting up a new host. Less common but real: the target's CHAP settings got reset during firmware update.

Fix Steps (Primary)

1. Verify CHAP credentials on the target side
   Log into your storage array (Dell EMC, NetApp, TrueNAS, etc.) and check the CHAP settings for that particular iSCSI target. Write down the exact username and password – including uppercase, lowercase, and special characters.
2. Match on the initiator
   On Windows: Open iSCSI Initiator, go to Configuration tab, click CHAP. Enter the same username and password. On Linux (iscsiadm):
   

   iscsiadm -m node -T  -p  -o update -n node.session.auth.authmethod -v CHAP
   iscsiadm -m node -T  -p  -o update -n node.session.auth.username -v 
   iscsiadm -m node -T  -p  -o update -n node.session.auth.password -v 

   Run iscsiadm -m session --rescan to retry login.
3. Check mutual CHAP if enabled
   If the target requires mutual authentication, you also need to set the target's credentials on the initiator side. On Windows: In iSCSI Initiator, go to Target portals, select the target, click Advanced, then check Enable CHAP logon and Perform mutual authentication. Enter both initiator CHAP and target CHAP secrets. On Linux:
   

   iscsiadm -m node -T  -p  -o update -n node.session.auth.chap_auth -v 2
   iscsiadm -m node -T  -p  -o update -n node.session.auth.username_in -v 
   iscsiadm -m node -T  -p  -o update -n node.session.auth.password_in -v 

4. Verify initiator name
   The initiator's IQN must exactly match what the target expects. One-off characters break it. On Windows: Check in iSCSI Initiator Configuration tab. On Linux: cat /etc/iscsi/initiatorname.iscsi. Update the target's allowed initiators list if needed.
5. Test with a simple password
   Temporarily set a basic CHAP password (like 'test123') on both sides to isolate the issue. If it connects, the problem is your original password – maybe it has unsupported characters or length exceeds 12-16 bytes (varies by target).

Alternative Fixes (If Primary Fails)

• Reboot the initiator – sounds stupid, but I've had iSCSI stacks get stuck after repeated auth failures. A clean startup flushes stale sessions.
• Check firewall rules – iSCSI uses port 3260. If a firewall blocks it, you won't even get to auth. Use telnet or nmap to verify connectivity.
• Disable CHAP temporarily – On the target, set authentication to None for a test. If it connects without CHAP, the issue is definitely credential mismatch. Don't leave it disabled in production.
• Check target logs – Storage arrays log auth failures. Look for clues like 'CHAP user not found' or 'CHAP secret rejected'. That pinpoints whether it's the initiator name or password.
• Update iSCSI drivers – On older Linux kernels (pre-4.0) or Windows Server 2012, there were CHAP bugs. Update the initiator software or use a newer OS if possible.

Prevention Tip

Standardize your CHAP passwords. Use a consistent format like chap-- and store them in a password manager, not a sticky note. Document mutual CHAP separately – many admins forget which direction is which. When you change passwords on the target, do it during a change window and update initiators immediately after. Don't batch changes across multiple hosts – do one, test, then move to the next.

Also, enable iSCSI logging on your initiators. Windows: Event Viewer > Applications and Services > Microsoft > Windows > iSCSI. Linux: set iscsid.conf log level to 1. When auth fails again, you'll have logs to trace it fast.