Trouble connecting Win 11 iSCSI though ESXi works

TrueNAS General
1

Hello,

I have (2) TrueNAS Core boxes (both latest update). One has been attached to and running to (2) ESXi boxes and (1) Windows 11 box for several years (iSCSI connection). I am trying to migrate to the second TrueNAS server. I setup everything the same, and the ESXi boxes connected up right away with full failover and working great. I can’t get the Windows 11 box to connect. My process:
on TrueNAS:
Setup portal IPs

on Windows (or ESXI, same process):
Add the TrueNAS portal IPs to the “discover portal” tab in the iSCSI initiator window. Click the “Targets” tab and hit “Refresh”.

Normally, I’d see the initiators in the “Initiator groups” tab on TrueNAS, add them in, assign the target, extent, and associate target. Then go back to Windows and refresh and the drive is there.

I am not getting any errors in Windows, but not getting the initiators to show up in TrueNAS. A Packet Capture shows the login IS successful, but they aren’t showing up.
New/Old TrueNAS on same set of VLANs, no IP conflicts, MTU matches everywhere. Still no joy on Win 11.

TrueNAS on 192.168.2.6 (and 192.168.3.6) and Windows box on 192.168.2.10 (and 192.168.3.10)

Also tried “Quick connect” in the Windows initiator and it also produces no results.

Tried everything I can think of, and not sure where to look next. Any thoughts appreciated.
Thanks.
James

ps- I can’t seem to find a way to include the screen shot of the PCAP, but I do have it…

2

From the Windows system, can you telnet 192.168.2.6 3260 and get a connection? You might need to go into Control Panel and install telnet as a Windows feature if it’s not already. Or use your favorite terminal client…

I presume 192.168.2.x vs 3.x is to have interfaces in separate subnets due to multipathing? I have a similar setup wired point-to-point (no switch) and something that occasionally trips me up is assigning the wrong IP to a given interface. In other words if my 192.168.2.x interface is hard-wired to the 192.168.3.x server interface of course it won’t work (different subnets)…

On the TrueNAS side, can you open a terminal Window and watch journalctl -f while making the connection attempts? The SCST iSCSI target daemon drops some nice, easy to read entries into the journal when a client connects.

Edit: I doubt this is the problem but just in case… Windows counts MTU bytes differently. MTU 9000 in TrueNAS is 9014 in Windows. My client will connect with an MTU mismatch – perhaps with degraded performance – but I don’t know that another system would do likewise. Maybe I’ve twiddled an MTU discovery knob somewhere that I’ve forgotten about.

3

Hi Richard,

Thanks for the great insights here! I should have posted originally that yes, I have connectivity between the box and TrueNAS, ping and telnet work, and as I had mentioned, the packet capture I did with wireshark shows the WIndows 11 box actually does a successful login (and logout, so maybe that’s some kind of problem??) Yes, I have 2 switches in between all of this as everything is multi-pathed.

Your journalctl idea is a good one, but this is TrueNAS Core, not Scale, so it’s BSD based and that command doesn’t exist. I did some searching to see if there was anything like it (I am far more familiar with the more common Linux’es than FreeBSD) but I found really nothing that might compare so far.

I have matched MTUs. I used the config from the working box to setup the new box to make sure everything matched. It’s kind of odd because EVERYTHING is the same, exact same hardware, exact same software versions, everything. One works, the other doesn’t.

I was going to use TrueNAS scale for this project as an upgrade path, but I found it a lot harder to find all the things I needed to change/config/adjust. I am positive it’s all there, I just didn’t have time to learn a new platform before rolling this out. I guess I could try to build it out on Scale and see if anything is different.

I wish I could upload the packet capture to show the interaction, but this forums says “Sorry, new users can’t upload files”. In any case, here’s the contents of the relevant packets (without payload details) showing success:

192.168.2.10 192.168.2.6 iSCSI 198 Login Command
192.168.2.6 192.168.2.10 TCP 60 [TCP Window Update] 3260 → 50152 [ACK] Seq=1 Ack=1 Win=1057280 Len=0

192.168.2.6 192.168.2.10 iSCSI 118 Login Response (Success)

192.168.2.10 192.168.2.6 iSCSI 102 Logout Command (Close session)

192.168.2.6 192.168.2.10 iSCSI 102 Logout Response

So the boxes are absolutely talking to each other. This has to be something in config. Just can’t figure it out since the boxes look to be identical from a configuration standpoint (clearly something isn’t the same!!!)

Thanks.
James

4

tail -f /var/log/syslog perhaps? I don’t have a BSD system here to try this on. Also I’ve no idea if iSCSI errors on Core would show up here or in their own separate logfile.

Anything interesting in the Windows event log?

5

Please add the CORE tag to your original post. It may help with feedback