LFCE 112 🐧 iSCSI — Concepts - KandZ

⏱️ Estimated read: 14 min | |

iSCSI is the protocol that carries SCSI commands over TCP/IP. It exists because block storage has traditionally required direct attachment or a dedicated Fibre Channel fabric, and neither scales cheaply across a standard Ethernet network. iSCSI extends the SCSI architectural model onto ordinary IP infrastructure, letting a server treat a remote disk as if it were locally attached, while the storage itself sits on a separate machine or appliance reachable over the network .

Quick How-To Guides & Fast FixesNeed a quick fix or step-by-step solution? Browse our fast answers on HowTo.KandZ.me:

Operating Systems CLI →Dev Environment Languages →Web Network Tools →Security Accounts →Security Access Tech →Device Phone Basics →Social Messaging →Digital Files Media →

This chapter covers the conceptual foundation, not the configuration. It explains the two roles in every iSCSI relationship, the naming scheme that identifies them, the session model that governs how they communicate, and the security mechanisms that sit between them. By the end, you will understand what an IQN is, why a target is more than an IP address, how an initiator and target establish a session, and what CHAP does that a firewall does not.

Key point: iSCSI is not a filesystem protocol and it is not a network share. It presents a remote block device to the initiator’s kernel, and the initiator formats and mounts it exactly as it would a local disk. The target does not know or care what filesystem is on the LUN it exports.

Why iSCSI exists

The dedicated fabric cost problem. Fibre Channel provides block-level storage access with predictable performance and mature isolation, but it requires HBAs, FC switches, and separate cabling. For environments that already have gigabit or ten-gigabit Ethernet, iSCSI reuses that infrastructure and eliminates the second physical network . The trade-off is that storage traffic shares links with general network traffic unless a dedicated VLAN or physical segment is configured.

The block versus file distinction problem. NFS and SMB present files and directories. iSCSI presents a raw block device. This matters for applications that require direct control over a block device: databases that manage their own I/O patterns, clustered filesystems that need to coordinate locking at the block layer, and hypervisors that present raw LUNs to virtual machines. iSCSI gives those workloads remote block access without a Fibre Channel fabric .

The distance problem. SCSI cables have strict length limits. iSCSI inherits TCP/IP’s routability, so the target can be in another rack, another building, or another site, subject to latency and bandwidth constraints. This is not free: iSCSI over a WAN is sensitive to latency, and the protocol’s error recovery and timeout behavior assume a reasonably responsive link.

The multipath problem. A single Ethernet link is a single point of failure. iSCSI is designed to support multiple sessions between an initiator and a target, and multiple paths through the network. The initiator can load-balance across paths and fail over when one path drops, provided the target exports the LUN through multiple portals. This is the iSCSI equivalent of multipathing in Fibre Channel, and it is a first-class concern in production deployments.

a. Initiator and target

Every iSCSI relationship has exactly two roles. The initiator is the client: it sends SCSI commands and receives responses. The target is the server: it receives commands, executes them against its backing storage, and returns status and data. In Linux terms, the initiator is the kernel’s iSCSI subsystem plus a userspace daemon, and the target is either a kernel module or a userspace daemon exporting LUNs .

The roles are not symmetric. An initiator cannot be a target without running separate software, and a target does not initiate connections to initiators. The initiator connects to the target’s portal, which is an IP address and TCP port. The default port is 3260 .

A single target machine can export many LUNs, and a single initiator can connect to many targets. The relationship is many-to-many at the node level, but each session is a one-to-one relationship between an initiator port and a target portal group.

b. Naming: IQN, ISID, and Portal Group Tag

iSCSI does not identify nodes by IP address. It uses a name string, up to 223 bytes, called an iSCSI Qualified Name (IQN). The IQN is the primary identifier for both initiators and targets . An IQN has a defined format: the string iqn., a date code, a reversed domain name, and an optional free-form suffix. For example, iqn.2024-01.com.example:storage.target01.

The IQN is not the whole story. A complete iSCSI identity includes additional qualifiers :

The initiator is identified by its IQN plus a 6-byte ISID (Initiator Session ID). The ISID distinguishes multiple sessions from the same initiator node to the same target.
The target is identified by its IQN plus a 16-bit Portal Group Tag (TPGT). The tag identifies which portal group the target is listening on, allowing a single target IQN to be reachable through multiple IP addresses or interfaces.

The full I_T nexus—the relationship between one initiator port and one target port—is identified by the tuple (initiator IQN + ISID, target IQN + TPGT) . This is what the target uses to decide which LUNs are visible to which initiator.

c. Sessions, connections, and command ordering

An iSCSI session is the logical relationship between an initiator and a target portal group. A session can contain one or more connections, which are individual TCP connections. Multiple connections within a session provide fault tolerance and, in some configurations, aggregated bandwidth. If one connection fails, the session can survive on the remaining connections.

Commands are numbered within a session. Each command carries a CmdSN (Command Sequence Number), a 32-bit counter allocated by the initiator . The target acknowledges commands in order. This numbering exists to guarantee ordered delivery of SCSI commands, because TCP guarantees byte-stream delivery but not application-level ordering across multiple connections or after error recovery.

The target must deliver commands for execution in CmdSN order, except for commands marked for immediate delivery. Immediate commands carry a CmdSN but do not advance the counter; they are used for task management and other operations that must not wait behind queued I/O . This distinction matters for error handling: a task management command that aborts a hung I/O must be able to reach the target before the I/O it is meant to abort.

d. Security: CHAP and what it does

iSCSI has no built-in encryption. The protocol carries SCSI commands and data in cleartext over TCP. If confidentiality is required, IPsec or a separate encrypted tunnel must be used, and that is outside the iSCSI protocol itself.

What iSCSI does provide is authentication through CHAP (Challenge Handshake Authentication Protocol). In one-way CHAP, the target challenges the initiator, and the initiator proves knowledge of a shared secret. In mutual CHAP, the initiator also challenges the target, so both sides prove identity . This prevents an unauthorized initiator from connecting to a target and reading or writing its LUNs, and it prevents an initiator from connecting to a rogue target that is impersonating the real one.

CHAP is not authorization in the granular sense. It authenticates the initiator’s identity, and the target then decides which LUNs to expose to that IQN. The IQN is the basis for LUN masking: the target’s configuration maps initiator IQNs to LUNs, and an initiator that authenticates successfully but has no LUNs mapped to its IQN sees no storage.

Complete Example Session

# ============================================
# PART 1: THE INITIATOR IQN FORMAT
# ============================================
# iqn.YYYY-MM.reverse-domain:optional-suffix
# Example:
iqn.2024-01.com.example:client01

# The initiator IQN is configured on the client.
# It is presented to the target during login.
# The target uses it to decide which LUNs to expose.

# ============================================
# PART 2: THE TARGET IQN AND PORTAL GROUP TAG
# ============================================
# Target IQN:
iqn.2024-01.com.example:storage.disk01

# Portal Group Tag (TPGT): 1
# The TPGT identifies which portal group the target
# is listening on. A single target IQN can have
# multiple portal groups, each with its own IPs.

# Discovery address format:
# <IP>:3260
# The initiator sends a SendTargets request here
# and receives a list of target IQNs and portals.

# ============================================
# PART 3: THE I_T NEXUS
# ============================================
# The full relationship identifier:
# (Initiator IQN + ISID, Target IQN + TPGT)
#
# Example tuple:
# (iqn.2024-01.com.example:client01 + 0x0001,
#  iqn.2024-01.com.example:storage.disk01 + 1)
#
# The ISID distinguishes sessions from the same
# initiator. The TPGT distinguishes portal groups
# on the same target.

# ============================================
# PART 4: SESSION AND CONNECTION STRUCTURE
# ============================================
# One session = one I_T nexus
# A session may contain multiple TCP connections.
#
# Session: client01 -> storage.disk01, TPGT 1
#   Connection 1: 192.168.10.10:49152 -> 192.168.10.20:3260
#   Connection 2: 192.168.10.11:49153 -> 192.168.10.21:3260
#
# Multiple connections provide failover.
# If one path fails, the session persists on the other.

# ============================================
# PART 5: CmdSN ORDERING
# ============================================
# Initiator allocates CmdSN sequentially:
# Command A: CmdSN 100
# Command B: CmdSN 101
# Command C: CmdSN 102
#
# Target must execute A, B, C in that order.
# Exception: immediate commands do not advance CmdSN.
# A task management command may carry CmdSN 103
# without incrementing the counter.

# ============================================
# PART 6: LUN MASKING BY IQN
# ============================================
# Target configuration (conceptual):
# LUN 0 -> exposed to iqn.2024-01.com.example:client01
# LUN 1 -> exposed to iqn.2024-01.com.example:client02
#
# client01 authenticates and logs in.
# It sees LUN 0 only. LUN 1 is invisible.
#
# Authorization is not "can this initiator connect?"
# It is "which LUNs are mapped to this IQN?"

# ============================================
# PART 7: ONE-WAY CHAP
# ============================================
# Target challenges initiator.
# Initiator proves knowledge of shared secret.
# Target does not prove its identity.
#
# Configuration (conceptual):
# Target: CHAP user "client01", secret "s3cret"
# Initiator: CHAP user "client01", secret "s3cret"
#
# If the secret does not match, login fails.
# If it matches, the session is established.

# ============================================
# PART 8: MUTUAL CHAP
# ============================================
# Both sides challenge each other.
# Target authenticates to initiator as well.
#
# Initiator config:
#   target CHAP user: "storage01"
#   target CHAP secret: "t4rget"
#   local CHAP user: "client01"
#   local CHAP secret: "s3cret"
#
# Target config:
#   initiator CHAP user: "client01"
#   initiator CHAP secret: "s3cret"
#   local CHAP user: "storage01"
#   local CHAP secret: "t4rget"

# ============================================
# PART 9: DISCOVERY VS LOGIN
# ============================================
# Discovery: SendTargets to <IP>:3260
#   Response: list of "TargetIQN,TPGT,PortalIP"
#
# Login: initiate session to a specific target portal
#   Authenticate (CHAP if configured)
#   Negotiate parameters
#   Session established
#
# Discovery does not authenticate the initiator
# for data access. Login does.

# ============================================
# PART 10: WHAT THE INITIATOR SEES
# ============================================
# After successful login, the initiator kernel
# sees a new SCSI device:
# /dev/sdb
#
# The initiator can partition it, format it,
# and mount it like any local disk.
#
# The target does not know the filesystem type.
# It exports blocks, not files.

The ten parts covered the identifier format, the target portal group, the I_T nexus tuple, session and connection structure, command ordering, LUN masking, one-way and mutual CHAP, the difference between discovery and login, and the block-device view the initiator receives.

Quick Reference

The identifiers

Identifier	Owner	Size	Purpose
IQN	Initiator or target	Up to 223 bytes	Node name
ISID	Initiator	6 bytes	Distinguishes sessions from one initiator
TPGT	Target	16 bits	Distinguishes portal groups on one target
I_T nexus	Both	Tuple	Full relationship identifier

The roles

Role	Function	Default port
Initiator	Sends SCSI commands, receives responses	Ephemeral
Target	Receives commands, executes against LUNs	3260

The session model

Concept	Meaning
Session	Logical relationship between initiator and target portal group
Connection	Individual TCP connection within a session
CmdSN	32-bit command sequence number, session-wide
Immediate command	Carries CmdSN but does not advance it
I_T nexus	One initiator port to one target port

Security mechanisms

Mechanism	What it provides	What it does not provide
CHAP (one-way)	Initiator authentication	Target authentication, encryption
Mutual CHAP	Both sides authenticate	Encryption
LUN masking	Maps LUNs to initiator IQNs	Authentication by itself
IPsec	Encryption and integrity	iSCSI-native; requires separate configuration

Discovery and login

Phase	Command	Purpose
Discovery	SendTargets	List available targets and portals
Login	Session login	Establish I_T nexus, authenticate, negotiate

Best Practices

✅ Do This:

# Use a consistent IQN scheme across the environment
iqn.2024-01.com.example:client01                        # ✅

# Configure mutual CHAP in untrusted networks
# Both sides prove identity, not just the initiator
# (conceptual) enable mutual CHAP on both ends         # ✅

# Use a dedicated VLAN or physical segment for iSCSI traffic
# Storage traffic should not compete with user traffic
# (conceptual) separate VLAN for 3260                    # ✅

# Map LUNs to specific IQNs, not to "any initiator"
# LUN masking is the authorization boundary
# (conceptual) LUN 0 -> client01 only                    # ✅

# Use multiple connections in a session when paths are redundant
# Failover survives a single link loss
# (conceptual) two connections, two paths                # ✅

# Keep initiator and target IQNs documented
# The I_T nexus tuple is the audit trail
# (conceptual) inventory of IQNs                         # ✅

❌ Don’t Do This:

# Assume iSCSI encrypts data
# It does not; SCSI commands and data are cleartext
# (conceptual) iSCSI alone for sensitive data           # ❌

# Use IP addresses as the only identifier
# The IQN is the identity; IPs change
# (conceptual) allow by IP only                          # ❌

# Expose a LUN to all initiators by default
# LUN masking must be explicit per IQN
# (conceptual) no mapping = no access                    # ❌

# Run iSCSI and general traffic on the same unseparated link
# Contention causes latency and timeout errors
# (conceptual) single flat network for everything        # ❌

# Confuse discovery with authorization
# Discovery lists targets; it does not grant LUN access
# (conceptual) SendTargets response = access             # ❌

# Use one-way CHAP when the target's identity matters
# An initiator can connect to a rogue target
# (conceptual) one-way CHAP in an untrusted fabric        # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Initiator logs in but sees no LUNs	No LUN mapping for its IQN	Map LUN to the initiator IQN on the target
Login fails with CHAP error	Secret mismatch or wrong CHAP direction	Verify secret and one-way vs mutual CHAP configuration
Session drops when one cable fails	Session has only one connection	Configure multiple connections across separate paths
Target unreachable after IP change	Initiator is configured with old portal IP	Update discovery or login address; IQN unchanged
Performance degrades under load	iSCSI shares link with user traffic	Separate VLAN or physical interface for storage
Initiator sees a different LUN than expected	LUN masking maps the wrong IQN	Check IQN string character-for-character

Real-World Examples

1. Initiator IQN example

iqn.2024-01.com.example:client01

2. Target IQN with portal group

iqn.2024-01.com.example:storage.disk01,1

3. Discovery address

192.168.10.20:3260

4. I_T nexus tuple

(iqn.2024-01.com.example:client01 + ISID 0x0001,
 iqn.2024-01.com.example:storage.disk01 + TPGT 1)

5. Session with two connections

conn1: 10.0.0.10:49152 -> 10.0.0.20:3260
conn2: 10.0.0.11:49153 -> 10.0.0.21:3260

6. LUN masking by IQN

LUN 0 -> iqn.2024-01.com.example:client01
LUN 1 -> iqn.2024-01.com.example:client02

7. One-way CHAP credential

user: client01
secret: (shared secret on both sides)

8. Mutual CHAP adds target identity

target user: storage01
target secret: (shared secret on both sides)

9. Immediate command behavior

CmdSN advances for normal commands only.
Task management command carries CmdSN but
does not increment the counter.

10. Block device on initiator

/dev/sdb  (after login and LUN discovery)

Visual

The initiator-target relationship

┌─────────────────────────────────────────────────────────────┐
│  INITIATOR AND TARGET                                        │
│                                                              │
│  ┌──────────────────┐         ┌──────────────────┐          │
│  │   INITIATOR      │         │     TARGET       │          │
│  │                  │         │                  │          │
│  │  IQN             │         │  IQN             │          │
│  │  client01        │         │  storage.disk01  │          │
│  │                  │         │                  │          │
│  │  Sends SCSI      │────────►│  Receives SCSI   │          │
│  │  commands        │  TCP    │  commands        │          │
│  │                  │  3260   │                  │          │
│  │  Sees /dev/sdb   │◄────────│  Exports LUNs    │          │
│  └──────────────────┘         └──────────────────┘          │
│                                                              │
│  The initiator formats and mounts /dev/sdb.                  │
│  The target does not know the filesystem type.               │
└─────────────────────────────────────────────────────────────┘

The I_T nexus tuple

┌─────────────────────────────────────────────────────────────┐
│  I_T NEXUS IDENTIFIER                                        │
│                                                              │
│  ( Initiator IQN + ISID , Target IQN + TPGT )               │
│                                                              │
│  ┌─────────────────────┐   ┌─────────────────────┐          │
│  │ client01            │   │ storage.disk01      │          │
│  │ + ISID 0x0001       │   │ + TPGT 1            │          │
│  └─────────────────────┘   └─────────────────────┘          │
│                                                              │
│  This tuple identifies one session.                          │
│  A second session from the same initiator has a              │
│  different ISID. A second portal group has a                 │
│  different TPGT.                                             │
└─────────────────────────────────────────────────────────────┘

Session and connection structure

┌─────────────────────────────────────────────────────────────┐
│  SESSION WITH MULTIPLE CONNECTIONS                           │
│                                                              │
│  SESSION (one I_T nexus)                                     │
│    │                                                         │
│    ├── Connection 1 ── TCP ──► Portal 1 (10.0.0.20:3260)    │
│    │                                                         │
│    └── Connection 2 ── TCP ──► Portal 2 (10.0.0.21:3260)    │
│                                                              │
│  If Connection 1 fails, the session continues on             │
│  Connection 2. The I_T nexus is unchanged.                   │
│                                                              │
│  Commands are numbered with CmdSN across the                 │
│  entire session, not per connection.                         │
└─────────────────────────────────────────────────────────────┘

LUN masking by IQN

┌─────────────────────────────────────────────────────────────┐
│  LUN MASKING                                                 │
│                                                              │
│  Target configuration:                                       │
│                                                              │
│  ┌─────────────────────────────────────────────┐            │
│  │  LUN 0  ──►  iqn...client01                 │            │
│  │  LUN 1  ──►  iqn...client02                 │            │
│  │  LUN 2  ──►  (not mapped)                   │            │
│  └─────────────────────────────────────────────┘            │
│                                                              │
│  client01 logs in:                                          │
│    Authenticates via CHAP                                   │
│    Target checks LUN map for client01's IQN                 │
│    client01 sees LUN 0 only                                 │
│                                                              │
│  Authentication proves identity.                             │
│  LUN masking determines visibility.                          │
└─────────────────────────────────────────────────────────────┘

Summary

Item	Value
Protocol	SCSI commands over TCP/IP
Default port	TCP 3260
Initiator	Client that sends SCSI commands
Target	Server that exports LUNs
Node identifier	IQN (up to 223 bytes)
Session qualifier	ISID (initiator), TPGT (target)
Full relationship	I_T nexus tuple
Command ordering	CmdSN, session-wide, 32-bit
Authentication	CHAP (one-way or mutual)
Encryption	Not provided by iSCSI
Authorization	LUN masking by initiator IQN

Key takeaways:

iSCSI carries block-level SCSI commands, not files. The initiator sees a raw device, and the target does not interpret the filesystem on it.
The IQN is the identity, not the IP address. LUN masking maps LUNs to IQNs, and CHAP authenticates the IQN holder.
A session is identified by a tuple, not a single name. The I_T nexus combines initiator IQN + ISID with target IQN + TPGT.
CmdSN guarantees ordered command delivery. Immediate commands carry the number but do not advance it, which lets task management bypass queued I/O.
CHAP authenticates, LUN masking authorizes. Successful login does not grant LUN access; the target’s mapping does.
iSCSI is cleartext by default. Confidentiality requires IPsec or an encrypted tunnel outside the protocol.

Remember: iSCSI exists to bring block storage onto standard IP networks without a Fibre Channel fabric. The protocol’s core concepts are the two roles, the IQN identity scheme, the I_T nexus that defines a session, the CmdSN ordering mechanism, and the separation between authentication (CHAP) and authorization (LUN masking). Every configuration command in the next chapter—discovery, login, CHAP setup, LUN mapping—is an expression of one of these concepts. If you can describe the I_T nexus tuple and explain what CHAP proves and what LUN masking decides, you understand iSCSI at the level the LFCE expects.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!