Review TrueNAS iSCSI listener and initiator scope separately

Bottom line: Write the permitted storage clients before creating the target. Compare the listening addresses, initiator scope and authentication fields separately rather than assuming that selecting one of them establishes the other two.

Source fact: what the authority says

The TrueNAS iSCSI guide says portal address 0.0.0.0 listens on all IPv4 addresses and :: listens on all IPv6 addresses. Its wizard permits all initiators when the Initiators field is blank. The manual configuration provides an Allow All Initiators choice or a restricted initiator list. The guide separately describes no discovery authentication, CHAP for one-way authentication and Mutual CHAP for two-way authentication.

What the source does not establish

These are documented configuration choices, not proof of isolation on a particular storage network. This article makes no claim that CHAP encrypts storage traffic or that a successful login establishes the correct extent, filesystem or application behavior.

Applicability questions

• Which portal addresses should accept the approved storage traffic?
• Which initiators are intended to reach this target?
• What target and discovery authentication arrangement has the owner approved?
• What separate network and workload evidence is required before data is attached?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a target worksheet with portal address, intended client identities, authentication requirement and extent reference in separate fields. Have storage and network owners compare it with the actual interface and address inventory. Do not accept a wildcard listen address merely because it makes the first connection easier.

For a proposed two-client test, identify one expressly permitted initiator and one that must be refused. Review the actual initiator restriction before saving the target. Keep allow-all configurations explicit exceptions requiring their own justification instead of leaving the intended population implicit in an empty field.

Choose the supported authentication arrangement from the reviewed requirement and current guide. Keep secrets out of screenshots and ordinary evidence. Do not replace a required authentication decision with a broader listener or treat the presence of CHAP fields as proof of a separately unreviewed transport-security property.

Use disposable storage for the pilot and verify the extent identity before allowing a client to attach it. Preserve the initial target and portal configuration. Agree a stop condition for an unexpected client connection or a mismatch between the requested and presented storage object.

Verification and evidence

Proposed verification: inspect the active portal, initiator list and selected authentication configuration against the worksheet. Attempt only the approved harmless discovery and connection checks from the permitted and refused clients. Record each client, destination address, requested target and observed decision without credential values.

After the access checks, perform the separately approved harmless storage operation on the disposable extent and reconcile its identity. Retain an unexpected connection or authentication result as a finding. Accept the tested target path only; require separate evidence for application recovery, production data integrity and network isolation.

Official references

• TrueNAS — Adding iSCSI Block Shares — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.