Unable to authenticate (Windows and Linux)

[master]

Dear Open-E Team

Im using open-e iscsi r3 since one year. at the beginning, the product worked fine (expect performance). now i have problems adding new iscsi targets. im unable to connect to the iscsi server. (windows and linux)
i receive on both operating systems the error message "unable to authenticate" even i have deactivated chap authentication on both sides!

Im using the following open-e software release:
Model: iSCSI-R3
Version: 2.32.DB00000000.2863
Release date: 2007-09-27


Open-E Lun Config:
100GB LUN
IP Restriction: Allow 10.0.254.11
Deny 0.0.0.0/0
No Chap authentication


Linux iscsi.conf:
node.startup = automatic

# *************
# CHAP Settings
# *************

# To enable CHAP authentication set node.session.auth.authmethod
# to CHAP. The default is None.
node.session.auth.authmethod = None

# To set a CHAP username and password for initiator
# authentication by the target(s), uncomment the following lines:
#node.session.auth.username = vmware-01
#node.session.auth.password = vmware1234567890

# To set a CHAP username and password for target(s)
# authentication by the initiator, uncomment the following lines:
#node.session.auth.username_in = username_in
#node.session.auth.password_in = password_in

# To enable CHAP authentication for a discovery session to the target
# set discovery.sendtargets.auth.authmethod to CHAP. The default is None.
#discovery.sendtargets.auth.authmethod = CHAP

# To set a discovery session CHAP username and password for the initiator
# authentication by the target(s), uncomment the following lines:
#discovery.sendtargets.auth.username = vmware-01
#discovery.sendtargets.auth.password = vmware1234567890

# To set a discovery session CHAP username and password for target(s)
# authentication by the initiator, uncomment the following lines:
#discovery.sendtargets.auth.username_in = username_in
#discovery.sendtargets.auth.password_in = password_in

iscsiadm output:
[root@vmware-01 ~]# iscsiadm -m discovery -t sendtargets -p 10.0.254.1
iscsiadm: Login failed to authenticate with target
iscsiadm: discovery login to 10.0.254.1 rejected: initiator error (02/01), non-retryable, giving up


What's going wrong?!

[masim]

This has many sides:

before we start giving ideas I recommend updating to the latest version.

Then, make sure there is no firewall preventing the connection (did you add a firwall?)

Make sure that CHAP is disabled - check it from the logs information. Also, check the ip of your host system. What IP you are using??

[master]

This has many sides:

before we start giving ideas I recommend updating to the latest version.

Then, make sure there is no firewall preventing the connection (did you add a firwall?)

Make sure that CHAP is disabled - check it from the logs information. Also, check the ip of your host system. What IP you are using??

Hi Masim

Now i have updated the system, the problems aren't solved.

There is no firewall between these hosts, and also not on the hosts.

Chap is disabled. How I can check it with the "logs information" you mentioned?

My IP Configuration:
open-E: 10.0.254.1/24
initiator: 10.0.254.11/24

Originally i tried 10.0.255.1/24 for the target and 10.0.255.11/24 for the initiator.
Unfortunatly the following settings didn't work, because the open-e gui didn't accept 10.0.255.11 for filtering!
I know the 10.0.255.0/24 is the so called "all ones subnet", but modern software must be able to handle it.
Is this issue solved, in the current version?

[masim]

Do you still have the problem?? if no, what was the solution???

[rewart01]

Thought I would throw up a possible fix, to complete this thread....

I was having the same problem adding new targets - all seemed well except that I couldn't get my hosts to connect to them. It was frustrating me, and got added to the "something I will deal with when I have time/must do" list.

I just realized that the volumes were setup in the volume replication section as destinations, not as a source. I changed it to source, rescanned the box, and low and behold it found it connected to the target without incident.

The sad thing is that there is even a warning message that shows up about it, but at the time I was dealing with it, I had much bigger fish to fry and apparently didn't read the warning.

Take care,
Rick

[To-M]

Thanks Rick!

You are correct you cannot connect to the destination volume during replication. So if failing over to the destination volume you have to change to source (clear the metadata) and then enable the target. But make sure to switch the source to destination and remove the target.