I recreated a certificate, but a reboot with version 85 gave me a "selftest OK" again, but still a blank screen.
Rebooted into version 80 and I'm back in...
While the ESX was still off, I removed the IP restrictions on all targets, so they were set to "ALL" on "Allowed" and disabled the CHAP authentication for all of them.
But still, no luck with adding the target portal to any MS iSCSI initiator...
It has been a while since I've been working on this issue (had to finish my degree first), so I guess it's time for an update:
From version 90 all was working fine again and I am currently running version 97 (latest).
I've been able to reproduce the errors. What appears to be the case?
Any Windows server that has a primary NIC in my LAN and is a domain member, fails when connecting through a dedicated NIC in the iSCSI LAN (or VLAN, in case of a virtual machine).
Contrary, any server that has its primary NIC in another LAN (or VLAN) and subnet, succesfully authenticates, all settings on the DSS being equal.
If you can place the Domain server on the same subnet as the ones that do connect maybe using a secondary nic and if this works could mean you have some firewall policy or other rules.
Many thanks for picking up this thread so quickly again!
In both cases, I've specified a dedicated NIC on the iSCSI subnet in the MS Initiator and from there, they use the exact same physical network structure and no firewalls are in place.
Could it somehow be related to the Domain membership of the DSS?
Even if the DSS was part of the Domain that would be for only NAS not iSCSI. There has to be something blocking the 3260 port or that the Domain servers have some policy to only use certain protocols. If the servers connect directly to the DSS even in the Domain with secondary nic and lets say you can use directly connect to the DSS via the Primary nic then that would point to something in the MS servers.