1

I've recently installed a synology NAS in a business environment. After setting up an iSCSI target, I went to one of the Windows Servers, launched the iSCSI initiator and could not discover the target. However, all of the Windows 10 machines could do it. I ran some tests with the Windows 10 machines against a few different iSCSI targets on the NAS and everything seems to be working. I can't get any of the Windows Servers to see the iSCSI target. We have Windows Server 2008 R2 and Windows Server 2012 R2 instances here. I tried 4 different servers.

Steps:

  • RDP into a Windows Server
  • Turn off Firewall (for this test) (actually iSCSI was explicitly open anyway)
  • Launch iSCSI Initiator
  • Click Discovery tab
  • Click Discover Portal
  • Enter hostname (fully qualified or short name didn't seem to help) (port is 3260)
  • Click OK (says Connection Failed)
  • Goto Targets Tab, press Refresh (there are no discovered targets)

I tried recreating the targets on the NAS side. Windows 10 can see and connect to them no problem, but not Windows Server 2008 R2 or Windows Server 2012 R2.

One possibility is that I need to explicitly add the IQN of the initiator (the Windows Server's IQN) to the NAS as a valid initiators. I got that idea from this link. I'm not sure how to do that with a synology and that seems weird since Windows 10 can get through. I don't yet see a place in the synology for specifying the initiator's IQN.

101010
  • 355
  • 7
  • 19
  • Hi, The server, NAS and win 10 are all in the same subnet ? Just to be sure its not a subnet error. – yagmoth555 Aug 15 '18 at 02:18
  • Yes, it's all one subnet. Same switch too. It's a passive switch. – 101010 Aug 15 '18 at 03:10
  • 1
    Try to specify IP of the Synology NAS instead of using iSCSI IQN in discovery tab in Microsoft iSCSI Initiator. In advanced settings of discovering choose Microsoft iSCSI Initiator as default Initiator, and specify Initiator IP (which must be in the same subnet as IP which discovering) – Strepsils Aug 15 '18 at 07:19
  • My solution in the end was to retire the Windows Server 2008 R2 and 2012 instances and replace them with 2016 instances. Heavy handed, yes. – 101010 Sep 08 '18 at 21:40

0 Answers0