iSCSI / IPSEC stale configuration issue
Hi, I am having an issue with the iSCSI initiator supplied with Windows7. For the past year or so, I have been connecting to a single iSCSI target without transport security (ie. IPSEC); everything has been great. Recently, I decided to configure IPSEC in order to test if transport security worked with my target; all worked well. After completing the test, I removed the target configuration and reconfigured the initiator to access the target WITHOUT IPSEC. Now, the initiator no longer works. The event viewer shows 2 relevant error messages: a) iSCSI discovery via SendTargets failed with error code 0x80320023 to target portal *192.168.1.109 0003260 Root\ISCSIPRT\0000_0 . b)Configuration of IPSEC was required, but failed with error code 0x80320023 for target address 192.168.1.109. Notes: *I have searched through the registry entries specified in the user’s guide; there are no obvious stale configuration entries. *if I access the same target, using a different ip address/portal, all works well (connects without IPSEC). *If I manually establish a tcp connection to the remote iscsi portal (ie. telnet); the connection succeeds (connects without IPSEC). Question: 1) There appears to be some bit of stale information that is causing the iSCSI initiator to require IPSEC when connecting to a specific portal: 192.168.1.109. Given that I can open the remote port manually, without IPSEC, this is likely not generic firewall rule. Instead, it appears to be unique the iSCSI initiator. So, what can it be? 2) Is there some way to manually reinstall the iSCSI initiator in Windows7? Since it is packaged with the operating system, the downloadable installer fails (ie. “system could not find the update.inf file…”)? 3) Is this the appropriate forum for these questions? Thanks, -Jonathan
September 15th, 2011 1:15pm

Hi Jonathan, I'm trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience. Regards, MiyaThis posting is provided "AS IS" with no warranties, and confers no rights. | Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
September 19th, 2011 2:24am

Hi, The likelyhood of this being a Firewall issue is much more after looking at the error code in our database. Most of the hits points at a firewall rule/policy conflict. Can you make sure that the firewall service is started and running correctly. Also inspect the firewall rules, make sure that there are no conflictine policies being applied to the firewall. Do report back, I'll keep researcing Sumesh P - Microsoft Online Community Support
September 20th, 2011 6:48am

Were you able to look through the firewall config?Sumesh P - Microsoft Online Community Support
Free Windows Admin Tool Kit Click here and download it now
September 27th, 2011 1:40pm

Sumesh, I have looked through the firewall configuration. The firewall is enabled and running without issue. I have no connection security rules defined. There are no firewall rules other than the system defaults. I have looked through the default rules to check for conflicts. I have a very basic configuration. As I said in my initial post, other applications can make outgoing requests to the remote ip and port without causing an IKE negotiation to occur. This problem smells like some sort of dynamic rule setup that the iSCSI service might be performing (incorrectly so). Only the developers can tell us if that is possible. -Jonathan
September 29th, 2011 4:20pm

Hi, Can you please follow this plan and let us know how it goes? 1. Remove all portals and targets from the iSCSI initiator 2. Export to a file the following registry key HKEY_LOCAL_MACHINE \SOFTWARE\Microsoft\Windows NT\Current Version\iSCSI 3. Delete the ‘All’ setting from the following registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\iSCSI\Discovery\Authentication Cache 4. Delete the ‘All’ setting from the following registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\iSCSI\Discovery\Tunnel Address 5. Reboot After that, you should be able to add in your portals and targets without getting that error about the displaydata.name being set to NULL. And the events 113 and 117 shouldn’t be seen anymore.Ketan Thakkar | Microsoft Online Community Support
Free Windows Admin Tool Kit Click here and download it now
October 6th, 2011 9:02am

Ketan, I can confirm that events 113 and 117 are no longer occurring. Also, the IKE negotiation is no longer occurring when the network transport is being established. My system appears fixed: many thanks. I have not tried to reproduce this issue, yet. Do you happen to known if this behavior is bug (ie. unable to disable IPSEC for a specific target portal). -Jonathan
October 6th, 2011 1:41pm

Hi folks, I came across this exact issue earlier today. Deleting the registry keys as described above and rebooting did the trick for me. I also think this may be a bug. I feel that removing the requirement for IPSec should remove all IPSec settings which are persisted without having to drop into the registry. Unless there is a good reason for persisting these settings. Thanks for posting this problem and thanks to those who have offered solutions. Austin
Free Windows Admin Tool Kit Click here and download it now
October 9th, 2011 6:47pm

The recommended way is to configure IPsec using the IPsec mmc snap-ins and then connect from iscsi using the defaults. The iscsi traffic would be IPsec encrypted. The IPsec configuration option in iscsi tools like iscsicpl and iscsicli shouldnt be used.Makarand Sonare
April 25th, 2012 10:25am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics