SOBR Linux iSCSI using mutual CHAP issues

[stephen.cilesio]

Hi,

I'm in the process of deploying Linux (Ubuntu 20.04) SOBR Repositories with NetApp E-Series as the target and using mutual CHAP as the authentication between the client (Linux Server) and the target (NetApp E-Series). According to all documentation i have set it up word for word but still no luck.

Just wondering if anyone has setup mutual chap for iSCSI within Ubuntu Server and how you accomplished that. What I've done is:

Configure the iqn name for the initiator

vi /etc/iscsi/initiatorname.iscsi

InitiatorName=iqn.2012-10.net.cpd:san.initiator01
InitiatorAlias=initiator01

Edit the iSCSI initiator configuration

vi /etc/iscsi/iscsid.conf

node.startup = automatic
node.session.auth.authmethod = CHAP
node.session.auth.username = initiator_user (IQN of Host Machine)
node.session.auth.password = initiator_pass

#The next two lines are for mutual CHAP authentication

node.session.auth.username_in = target_user (IQN of NetApp)
node.session.auth.password_in = target_password (Target Password)

Discover targets in the iSCSI server:

iscsiadm -m discovery -t sendtargets -p xxx.xxx.xxx.xxx

I get the - iscsiadm: discovery login to xxx.xxx.xxx.xxx failed, giving up 2
iscsiadm: Could not perform SendTargets discovery: encountered non-retryable iSCSI login failure

Made sure all passwords are the same, changed the passwords to a simple ones still nothing.

Is there anything i've missed or need to do?

[HannesK]

Hello,
I don't have a real answer for you, but in case you don't get an answer on the Veeam forums, I would recommend to check Netapp support or Ubuntu forums.

Is "normal" iSCSI at least working?

from https://www.netapp.com/pdf.html?item=/m ... 639pdf.pdf (I just hope that Solidfire and E-Series act similar).

this part looks missing in your description

Code: Select all

# discovery.sendtargets.auth.authmethod = CHAP
# discovery.sendtargets.auth.username = username
# discovery.sendtargets.auth.password = password

What does the Netapp support / logs say?

Best regards,
Hannes

[RubinCompServ]

Did you ever get this resolved?

[AlanHarrington]

Hello, spent more than a few hours on this, ended up working with netapp support. This is the following configuration used to make mutual chap work with e-series for a ubuntu 20.04 LTS repo. it's not for a sobr but just a normal linux hardened repository.

Working.
# *************
# CHAP Settings
# *************

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

node.session.auth.authmethod = CHAP

# To set a CHAP username and password for initiator
# authentication by the target(s), uncomment the following lines:
node.session.auth.username = iqn.2021-10.org.debian:veeam-repo01.randomiqn.com
node.session.auth.password = AuthRandom694T

# To set a CHAP username and password for target(s)
# authentication by the initiator, uncomment the following lines:
node.session.auth.username_in = iqn.2021-10.org.debian:veeam-repo01.randomiqn.com
node.session.auth.password_in = AuthRandom694I

# 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 = iqn.2021-10.org.debian:veeam-repo01.randomiqn.com
#note that's hashed out uptop, it's the bottom password that's important.
discovery.sendtargets.auth.password = AuthRandom694T

# 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 =
#discovery.sendtargets.auth.password_in =

and this is where we get the iqn, notice we don't need a send targets username and the username for node.session is repeated, that is on purpose. NetApp will updating there documents shortly to reflect the differences.
iqn.2021-10.org.debian:veeam-repo01.randomiqn.com = cat /etc/iscsi/initiatorname.iscsi

Hope that helps!

[Andreas Neufert]

Thanks for sharing this. Off topic for the products but helpful for our community.

Please allow me one comment. When you use external storage as hardened repository, make sure to not connect the management Port of the system to your network and use direct connections on the iSCSI side to avoid that someone destroys data on the backend.

[RubinCompServ]

Hello, spent more than a few hours on this, ended up working with netapp support. This is the following configuration used to make mutual chap work with e-series for a ubuntu 20.04 LTS repo. it's not for a sobr but just a normal linux hardened repository.

[snippy snip]

Hope that helps!

That does help, Alan, thanks! It looks like you used mutual CHAP for the actual volume connection but not for discovery, right? That's what I found during my testing, but couldn't get NetApp to confirm or deny that it was supposed to function like that.

[ratkinsonuk]

Just resurrecting this thread as I'm attempting to do the same.

Is there a way to specify more than one username/password in Linux? If I wanted to connect my server to multiple SAN's for instance, I'd need to use the same credentials for both? That sounds a bit insecure.

[RubinCompServ]

@ratkinsonuk,

I'm still a Linux neophyte but it does seem that way to me.

[ratkinsonuk]

Thanks Rubin. Not so great then.