# Review TrueNAS iSCSI listener and initiator scope separately > TrueNAS documents broad portal listen addresses and a separate allow-all initiator choice. Review listener placement, initiator restrictions and target authentication as different configuration decisions. - Canonical URL: https://update.dsesecurity.com/updates/review-truenas-iscsi-listener-and-initiator-scope-separately/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T19:49:33+00:00 - Modified: 2026-10-29T19:50:08+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know TrueNAS documents broad portal listen addresses and a separate allow-all initiator choice. Review listener placement, initiator restrictions and target authentication as different configuration decisions. ## Potentially affected TrueNAS 25.10 iSCSI portal and target configuration in the official block-share guide. ## DSE recommendation Review portal addresses, intended initiators and authentication independently, then test permitted and refused clients through the approved storage network. ## Article 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](https://www.truenas.com/docs/scale/25.10/scaletutorials/shares/iscsi/addingiscsishares/) 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](https://www.truenas.com/docs/scale/25.10/scaletutorials/shares/iscsi/addingiscsishares/) — 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. ## Primary reference - Name: TrueNAS — Adding iSCSI Block Shares - Authority: www.truenas.com - URL: https://www.truenas.com/docs/scale/25.10/scaletutorials/shares/iscsi/addingiscsishares/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Review TrueNAS iSCSI listener and initiator scope separately,” DSE Security, https://update.dsesecurity.com/updates/review-truenas-iscsi-listener-and-initiator-scope-separately/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.