iSCSI Target – TCP port exhaustion after repeated reconnects

Question

iSCSI Target – TCP port exhaustion after repeated reconnects

Emma Brooks 0

Hi,

We're seeing persistent disconnects between our SAN initiators and a Windows Server iSCSI Target Server. The clients repeatedly reconnect, but after a while the target becomes unable to accept new connections.

Diagnostics show thousands of TCP sockets stuck in TIME_WAIT, which appears to be exhausting the available ephemeral ports.

What is the recommended way to tune the TCP keep-alive settings and dynamic/ephemeral port range on Windows Server? Are there specific registry values we should adjust for an iSCSI workload with persistent connections?

Thanks.

AlexCodex 100 Reputation points

2026-08-13T08:22:54.95+00:00

I’d be careful about treating the ephemeral port range as the primary fix here. Thousands of TIME_WAIT sockets after repeated reconnects usually point to an underlying connection/reset problem that should be investigated first.

For an iSCSI workload, I would first check why the sessions are repeatedly disconnecting—network instability, NIC/driver issues, MPIO configuration, target service events, or storage/network timeouts. A persistent iSCSI session normally shouldn't be creating a large number of short-lived TCP connections.

Before changing registry values, capture the current configuration and confirm which ports are actually being exhausted. Also check whether the TIME_WAIT sockets are concentrated on one local address/port range.

If the workload genuinely needs more outbound ephemeral ports, Windows Server does provide supported mechanisms for configuring the dynamic port range, but I'd avoid blindly changing TcpTimedWaitDelay or other TCP registry settings just to hide the symptom. Reducing TIME_WAIT too aggressively can create its own problems.

I'd also verify that the iSCSI initiators are using persistent sessions/appropriate reconnect settings and that MPIO is configured correctly if multiple paths are involved.

In short: find the cause of the repeated reconnects first, then tune the port range only if diagnostics show that the available dynamic ports are actually the limiting resource. If you can post the Windows Server version, netstat/Get-NetTCPConnection output showing the TIME_WAIT sockets, and whether MPIO is being used, that would make the situation much easier to diagnose.

1 answer

Your answer

AlexCodex 100 Reputation points

2026-08-13T08:22:54.95+00:00

I’d be careful about treating the ephemeral port range as the primary fix here. Thousands of TIME_WAIT sockets after repeated reconnects usually point to an underlying connection/reset problem that should be investigated first.

For an iSCSI workload, I would first check why the sessions are repeatedly disconnecting—network instability, NIC/driver issues, MPIO configuration, target service events, or storage/network timeouts. A persistent iSCSI session normally shouldn't be creating a large number of short-lived TCP connections.

Before changing registry values, capture the current configuration and confirm which ports are actually being exhausted. Also check whether the TIME_WAIT sockets are concentrated on one local address/port range.

If the workload genuinely needs more outbound ephemeral ports, Windows Server does provide supported mechanisms for configuring the dynamic port range, but I'd avoid blindly changing TcpTimedWaitDelay or other TCP registry settings just to hide the symptom. Reducing TIME_WAIT too aggressively can create its own problems.

I'd also verify that the iSCSI initiators are using persistent sessions/appropriate reconnect settings and that MPIO is configured correctly if multiple paths are involved.

In short: find the cause of the repeated reconnects first, then tune the port range only if diagnostics show that the available dynamic ports are actually the limiting resource. If you can post the Windows Server version, netstat/Get-NetTCPConnection output showing the TIME_WAIT sockets, and whether MPIO is being used, that would make the situation much easier to diagnose.

Answer 1

Hello @Emma Brooks

The large number of TIME_WAIT connections is important, but I wouldn't treat TCP tuning as the primary fix yet. For a persistent iSCSI workload, thousands of short-lived TCP connections usually indicate sessions are repeatedly torn down and re-established.

Microsoft’s current iSCSI troubleshooting guidance specifically identifies network instability, MPIO configuration problems, NIC/driver issues, and storage connectivity problems as common causes of iSCSI disconnect/reconnect behavior.

I would first capture the current state while the problem is occurring:

Get-IscsiSession
Get-IscsiConnection
Get-NetTCPConnection |
    Group-Object State |
    Sort-Object Count -Descending
Get-NetTCPConnection -State TimeWait |
    Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort

Also check the configured dynamic TCP range:

netsh int ipv4 show dynamicport tcp
netsh int ipv6 show dynamicport tcp

On modern Windows Server versions, the default dynamic TCP range is normally 49152–65535. Microsoft supports changing this range using netsh if diagnostics confirm that dynamic ports really are being exhausted.

For example, the supported syntax is:

netsh int ipv4 set dynamicport tcp start=<start> num=<number-of-ports>

However, I wouldn't change this until you've confirmed that the initiator is actually exhausting its local dynamic ports. Increasing the range can provide additional headroom, but it won't fix whatever is causing persistent iSCSI sessions to disconnect.

I would also be cautious about changing TcpTimedWaitDelay. Reducing TIME_WAIT can make ports reusable sooner, but doing that simply to compensate for repeated iSCSI reconnects can mask the actual storage/network problem.

For the iSCSI side, I'd investigate:

Event Viewer for iSCSI/Storport events, particularly 9, 20, 27, 39, 129, and 153
NIC errors, drops, and link resets
NIC driver and firmware versions
MTU/Jumbo Frame consistency end-to-end
iSCSI network isolation/VLAN configuration
MPIO configuration and path stability
Target-side logs at the exact disconnect timestamps
Whether each MPIO/iSCSI path is using the intended dedicated NIC

Microsoft specifically recommends checking Get-IscsiConnection, Get-IscsiSession, MPIO configuration, network configuration, and current NIC/storage firmware when investigating iSCSI disconnects.

You can also collect a Windows network trace during a disconnect:

netsh trace start scenario=netconnection capture=yes tracefile=C:\Temp\iscsi.etl

Reproduce the disconnect/reconnect, then:

netsh trace stop

I'd correlate that trace with the iSCSI Target/Initiator and System event logs. That should tell you whether the initiator, target, or something along the network path is resetting the TCP sessions.

So I agree with the earlier response: don't start by aggressively lowering TIME_WAIT. First, determine why the supposedly persistent iSCSI connections keep closing. If you correct the root cause, port exhaustion will likely disappear.

Sharing these references with you:

iSCSI storage connectivity troubleshooting guidance

TCP/IP port exhaustion troubleshooting

If you can share the Windows Server version, output of Get-IscsiConnection, netsh int ipv4 show dynamicport tcp, and the relevant iSCSI/Storport event IDs around one disconnect, we can narrow down whether this is genuine port exhaustion or a symptom of the underlying iSCSI path failure.

Please "Accept the Answer" if this information helped you. This will help us and others in the community.