Not listening on port 3260

I'm running Open-E DSS v6 and with the last re-install of the VMWare ESX and ESXi servers I found the discovery of the targets no longer to work.
No CHAP authentication, nor IP restrictions apply to the test-target.

I was able to work around this issue by using full target names in the ESX(i) kickstart scripts.

Today I set out to fix this probleme and experienced similar problems connecting to iSCSI targets using Microsoft iSCSI Initiator (Windows 2008 R2 default) and Starwind iSCSI Initiator (latest version).

I found that the Open-E server is not listening on port 3260: only 21, 80, 139 and 445 are open.

Anybody any ideas how to fix this?

3260 can not be changed in the DSS V6 and it works - watch this video as we show it working.


http://www.open-e.com/library/webcasts-and-videos/
2011.03.15 DSS V6 iSCSI-Failover and Multipath with ESXi4.1

or

http://documents.open-e.com/Open-E_D..._ESX4i_4.1.pdf

Sorry for the quick follow up on my own post - I was mistaken with the port scan.
It seems port 3260 is open, but there is no response to any Initiator.

With the MS Initiator I get "Authentication failed" and Starwind says that the port is not opened.

Ports found open on the DSS are:

80
111
139
199
389
443
445
2049
3260
6666-6668
10000
11211

firewall?

DSSV6 isn't blocking anything ...

Thanks for the quick reply.

I've turned off the firewall on the initiator machine and I was able to ping both ways.

Furthermore, the ESX machine that has an active session to the DSS on port 3260 does not "discover" the new volume that I've made available to the appropriate CHAP user.

So, I should formulate more precisely: it is not port 3260 that is the problem, but somehow the target discovery is not working.

Is it possible I've accidentally turned it off at some point?

Did you add a lun to the iSCSI target? Is the lun # 0? Did you modify any of IP access controls for the target?

Sorry for the late response: I did not add a new LUN to an existing target, but created a new target instead.

There is no CHAP authentication enabled, but still MS iSCSI control panel reports "authentication failure".

Just checked: No IP controls are in place, and even the MS iscsi command line returned Authentication Failure on the command "iscsicli qaddtargetportal FQDN"

The eventviewer reports:

iSCSI discovery via SendTargets failed with error code 0xefff0009 to target portal *192.168.xxx.xxx 0003260 Root\ISCSIPRT\0000_0 .

The MS website (http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx) only explains that it is an Authentication Failure :mad:

This is regardless the OS (tried Win 7 and 2008 R2) or machine (tried 2 physical machines and 2 virtual machines)...

can you tell the MS initiator to look at the DSS IP, or have you done this?

in vmware, dynamic discovery can be disabled, if you are using static discovery.

Thank you for your reply!

I've tried by IP, using two machines on different subnets that both could ping the DSS (and vice versa), and FQDN.

I probably disabled the dynamic discovery in VMWare (is it by default? I never checked, since I install by kickstart script and use static discovery there), but I cannot see how that would be the cause the MS discovery authentication failure.

Any other ideas?

Am I the only one experiencing difficulties with Microsoft's native iSCSI?

See if you can telnet to the port and get an answer.
There isnt anything on the DSS side that would block it. In fact DSS will broadcast the LUN on each IP assigned to it.
You can try to remove the target and re-add it. This will not remove data, just don't delete the Volume.

I suspect something is blocking traffic in between the initiator and the LUN.

It's been a while since I've been struggling with this issue, but now that I'm trying to backup VMs using SAN access directly (using vStorage API), I'm running into this issue again.

What I am trying to do: access any DSS target using Microsoft's native (Win 2k8 R2) iSCSI initiator.

Even without CHAP and any IP restrictions, I get "Authentication Failure", no matter on what IP or from what machine I try to connect.

DSS is listening on port 3260, and I have a VMWare ESX 4.1 connected to one of the targets.
The problem solely exists when using Microsoft Initiator.

I'm stumped - this should be easy. What am I overlooking here?
Are there any requirements for the Initiator name?

Please, help!

Just to make sure that we are on the same page here, that the Windows 2008 server is NOT a virtual machine and the target that you are trying to connect is not being used by any other initiator.

If you can ping from the Windows 2008 server to the DSS being the same subnet and no VLAN and maybe try to directly connect the Windows 2008 directly to the DSS server to rule out any network issues from the Windows to the DSS side.

Also check the Windows event logs as well to see if there is any errors coming up.

Hi Todd

The 2008 R2 machine is a physical one and has an IP in the same subnet as the DSS server.
Actually, I tried two subnets, one in the default LAN and one in the iSCSI VLAN.

The iSCSI target on the DSS is a newly created one, but the error occurs already when connecting to the target portal on port 3260.

In both attempts, I was able to ping the DSS server.
Unfortunately, the windows logs do not reveal any more information.

The weird thing is: I remember having had the same issue a year or 2 ago, but about a year ago I once succesfully connected a Windows machine to a newly created target...
I simply can't think of any iSCSI setting I've changed since then...

Can you provide me a screen shot from the GUI (location below) or tell me if you see any connections to the Target?

MAINTENANCE -> Connections -> Function: iSCSI session manager

Is there any chance to directly connect a PC/Notebook and or the Windows to see if it will connect.

can you get a telnet reply on port 3260 from the windows box?

Hi

Currently, there is a VMWare ESX 5 machine connected to another target and the connection is properly shown in the location you mentioned (will post a screenshot tonight)

I have one spare NIC on the machine and I will see if I can connect a laptop directly and what the telnet response on port 3260 is, but that'll be tonight.

Will keep you posted...

Could it be that the ESX 4.1 and the ESX 5.0 that you mentioned in the other posts are connected to the targets? If so then using the Microsoft's (Win 2k8 R2) iSCSI initiator to the same targets wont work as the ESX are already connected to them.

Well, the ESX machine is connected to the existing targets (still need a screenshot?), but the problem happens with the newly created target.

<Offtopic>
I would like to use the vStorage API for backups, but that requires direct connection from the MS machine, where the backup software resides, to the target, wouldn't it?
</Offtopic>


I've succesfully added this new target to te ESX machines using static discovery, but the MS iSCSI client cannot even log onto the portal on port 3260, although it does connect (breaking connection gives 'connection error' instead of 'authentication error'.

Hopefully I find the time soon to connect a Windows notebook directly...

What I think what is happening here is that your ESX servers are connected to the targets and locking it out for the Windows systems. Use the Deny and Allow for the new target so that only the windows IP is allowed to connect to the target. For the API to windows I have no idea.

Hi Todd

I do not think this is the case: I allowed a subnet /24 to the targets and connect from an IP within that range.

Besides, I've also tried to connect with the IP restrictions removed from the new target IP.

I would love to try further, but my certificate had expired and I've just created a new one using the Time settings on the console, but the certificate is still invalid and no browser allows me to proceed.
I guess I need to reboot the DSS first?

Little update:

I connected a notebook with an IP in the correct range directly to the "spare" (but already configered for use in another subnet) NIC on the DSS and succesfully received a ping reply.

I then tried to connect using "iscsicli qaddtargetportal <IP-address>, but still the result is "Authentication failure".

I don't think IP restrictions are the problem, since I've already tried to connect from within the range that the ESX machine is also in.
Nevertheless, just to get this straight: any IP restrictions on specific targets should NOT affect the targetportal on port 3260, should they?

Next step will be more close examination of the DSS logs, but for now I still have the d*** certificate issue...

Maybe some screen shots to show some of the settings and outputs. Also download the log file then look for the tests.log and look for the "session" like below and post for the iSCSI sessions so we all can see. I have seen in the past many times before where there is another initiator connected to an iSCSI target. For you to now to have issues with getting into the browser tells me there is something else going on (port, duplicate name, separate network, subet, static route...). if rebooting works then possible cache of the browser - use Firefox possibly.

cat /proc/net/iet/session
*-----------------------------------------------------------------------------*

cat: /proc/net/iet/session: No such file or directory

*-----------------------------------------------------------------------------*
cat /proc/scsi_tgt/iscsi/session
*-----------------------------------------------------------------------------*


Also look in the tests.log and send us the info below.
*-----------------------------------------------------------------------------*
ifconfig -a
*-----------------------------------------------------------------------------*

At this point maybe a remote viewing might help. Can you send me an email via the forum and I will tell what to do next.

Thanks Todd for your assistance.

I will make one last attempt before calling for your help: I will shutdown the ESX, reboot the DSS machine so it runs the latest updates and no connections are running and try to connect.

If the cert issue (weird: removing the root from the trusted authorities in my personal store gets me to the login, but no further?) has been fixed, I will download some logs.

Will get back to you soon...

Make sure after rebooting the ESX server to use the reset function for the iSCSI Targets in Location
MAINTENANCE -> connections -> Function: iSCSI connection reset.

Hi Todd

This is clearly not my best day: I was able to fix the certificate issue by clearing the cache and downloading the SSLcert from the webinterface.

I did a reset of all iSCSI connections and tried again: no luck, still Authentication error.

I then rebooted the server to run with the latest updates, but now it only returns a blank page! No errors on the console and I can see the webserver is running by trying any non-existing path.
I tried on 3 machines, so I guess something is wrong with the update (85).
Let's reboot back into previous state...

Sounds for sure something is acting up. Any chance you can do a fresh install of the DSS V6 on another USB flash stick w/ the previous version like your doing now?

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...

Can you post the logs for us to see or to support.

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.

Now I'm getting really puzzled... :confused:

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?

I'll see if I can do some more testing tonight...

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.