Back to Blogs

iSCSI Troubleshooting, Security and MPIO Checklist

Diagnose failures in a fixed order—from network reachability to filesystem mount—then build a production design without single points of failure.

TroubleshootingStorage SecurityMPIOiSCSI
Dual-path iSCSI architecture and a seven-step troubleshooting sequence
iSCSI Troubleshooting, Security and MPIO cheat sheet: use this quick map before reading the detailed sections.

Troubleshoot in this order

  1. Can the initiator reach the target IP?
  2. Is TCP port 3260 open and listening?
  3. Does target discovery return the expected IQN?
  4. Does the ACL match the initiator IQN?
  5. Do CHAP credentials match?
  6. Is a LUN mapped to that ACL?
  7. Does the operating system detect the disk?
  8. Can the filesystem mount?
Why this order works: each check depends on the layer before it. It prevents a CHAP investigation when the real problem is a blocked port or wrong VLAN.

Target discovery returns no result

ping -c 4 192.168.50.10 nc -zv 192.168.50.10 3260 # On the Linux target ss -lntp | grep 3260 systemctl status target targetcli ls

Verify portal binding, target service state, host firewall, switch VLAN, subnet mask, routing and return path. Discovery cannot work until the initiator reaches the listening portal.

Login fails with an authentication error

  • The initiator IQN exactly matches the target ACL.
  • The CHAP username and secret are identical on both ends.
  • No extra spaces or quoting mistakes were introduced.
  • Target authentication is enabled where intended.
  • The ACL has access to the exported LUN.
journalctl -u iscsid --since "10 minutes ago" journalctl -u target --since "10 minutes ago"

Do not weaken access controls merely to make a login work. Compare identities and credentials methodically.

Login succeeds but no disk appears

Linux checks

iscsiadm -m session -P 3 lsblk lsscsi dmesg | tail -100

If required, rescan SCSI hosts:

for host in /sys/class/scsi_host/host*; do echo "- - -" > "$host/scan" done

Windows checks

Get-IscsiSession Get-Disk Update-HostStorageCache

If the session is healthy but no device arrives, inspect the target-side LUN mapping for this initiator ACL.

Sessions disconnect frequently

Look for packet loss, NIC errors, switch-port drops, mismatched MTU, VLAN mismatch, duplicate IP addresses, firewall timeouts, unstable routing, target overload and faulty cables or transceivers.

ip -s link ethtool -S eth1 journalctl -u iscsid # Use only when every hop is configured for jumbo frames ping -M do -s 8972 192.168.50.10
MTU must be end to end. Enabling jumbo frames on only the initiator or target creates hard-to-diagnose drops. Standard MTU is safer until the complete storage path is verified.

The disk is visible but cannot be mounted

lsblk -f blkid file -s /dev/sdb1 findmnt /mnt/iscsi-data

Confirm the expected filesystem and check whether another server already owns the LUN. Do not run filesystem-repair tools on a production LUN until every other writer is stopped and the storage owner is confirmed.

iSCSI does not reconnect after reboot

systemctl is-enabled iscsid systemctl is-enabled iscsi iscsiadm -m node -o show | grep -E "Target:|node.startup"

The node should report node.startup = automatic. A persistent filesystem entry should use the correct UUID and include _netdev. Confirm that network-online ordering works on the host.

A resilient design uses two initiator NICs, two independent switches, two target portals and a supported multipathing layer such as Linux device-mapper multipath or Windows MPIO.

Path resilience

  • Two storage NICs
  • Two separate switches
  • Two target portals
  • MPIO policy and failover tests

Operational resilience

  • Target-side high availability
  • Capacity and latency monitoring
  • Alerting for path loss
  • Regular restore testing
Test failure, not just success. During a maintenance window, verify that removing one NIC, switch path or portal does not interrupt the workload.

iSCSI security checklist

Never expose TCP 3260 directly to the public Internet.
  • Place iSCSI on dedicated storage VLANs or isolated fabrics.
  • Restrict firewalls to approved source and target addresses.
  • Create a specific ACL for each initiator IQN.
  • Use CHAP or mutual CHAP with strong, unique secrets.
  • Separate storage, management and user traffic.
  • Use IPsec when encryption is required.
  • Monitor logins, path state, latency, errors and capacity.
  • Back up configuration and test data restores.

An IQN ACL is useful access control, but it is not strong identity verification by itself. Combine it with network restrictions and authentication.

iSCSI Troubleshooting, Security and MPIO Frequently Asked Questions

Why does target discovery return nothing?

Verify IP reachability, TCP 3260, the target service, portal binding, firewall rules and routing—in that order.

Why does login succeed but no disk appears?

The target may not map a LUN to this initiator ACL. Inspect the detailed session, target object tree and operating-system storage state.

Should iSCSI be exposed to the Internet?

No. Restrict it to dedicated storage networks and authorised addresses. Use IPsec if storage traffic needs encryption.

Does production iSCSI need MPIO?

Workloads that require storage-path resilience should use supported multipathing with redundant NICs, switches and target portals.

References

Use Microsoft's iSCSI connectivity troubleshooting guidance and the relevant Red Hat initiator documentation alongside your storage vendor's support matrix.