NSS32x Admin Web UI Access

[Kurt Schumacher]

Configured port 8080 access to reach the NSS324 (admin) login portal. On connect, the portal page shows up, after the login (attempt), the connection goes to a timeout, and there is not access to the NAS.

Have neither configured a https redirect enforcement on the NSS, nor selected "use SSL" on the NSS login page of course. Similar problem with the NSS32x OEM devices by the way. No problems with RV0xx, ESW or WAP4410N Web UI access.

NSS324 log shows successful logins from the Thunderbolt appliance IP (10.10.1.31) here:

http://nss324:8080/cgi-bin/index.cgi#

http://nss324:8080/cgi-bin/index.cgi#

Type	Date	Time	Users	Source IP	Computer name	Connection type	Accessed resources	Action
	2010-09-04 9009	12:57:16	admin	10.10.1.25	---	HTTP	Administration	Login OK
	2010-09-04 9008	12:45:51	admin	10.10.1.31	---	HTTP	Administration	Login OK
	2010-09-04 9007	12:38:17	admin	10.10.1.31	---	HTTP	Administration	Login OK
	2010-09-04 9006	12:36:56	admin	10.10.1.31	---	HTTP	Administration	Login OK

[Marcos Hernandez]

Currently, the device support status for our SMB storage products is "yellow". We have it on the roadmap for First Service Availability, so x-launch to its device administraion UI will be officially supported.

Here is what the different colors mean:

Marcos

[Kurt Schumacher]

Not convinced this is very smart at this time. As of today, Thunderbolt is far too much network oriented, as it's Open Source parents are, most I know very well.

The detection quality of Cisco SB devices requires enhancing in this phase already. Monitoring of plain standard services available by default must become predefined once such devices are detected.

I know the NSS32x admin Web UI is slightly different than the simple ones on other device. What we are seeking for is simplicity in deployment - this requires a certain set of monitoring features automatically in place, according the standard services available, on either the Cisco SB devices, on Cisco IOS devices, and on third party computers, servers, network devices. The basic service set is very similar for the same device class. Beyond, I will push Thunderbolt to become a service-oriented platform as required by ITIL, and not a cloud based network node manager taking care of network devices or the most obvious host interfaces only. Properly implementing a complex device offering very different services - see the big detection poorness, making every NAS or Windows system with a UPnP/DLNA server simply an entertainment class device of a mediaserver type. Reminds me much to the first deployment of HP OpenView and IBM Tivoli NMM twenty years ago...at that time, it was SNMP, now other ugly preferences are in place.

Please concentrate on the priorities set in IT on SMB/SME environments - entertainment/mediaserver is among the last I want to present to the management when it comes to the non-inexpensive NAS sold hard into a business...

Thus, I will continue to be meticulous in this area.

-Kurt.

[jamwyatt]

Kurt,

The whole cross-launch process is somewhat interesting in general as many of

the devices that we connect to have never been tested/tried with any general

http proxy tools. In this case, the NSS32X device family requires that we

check the box 'SSL Login' on the main login page. Doing that allows it to

continue normally. Without it, it uses some JavaScript that it sent to the

browser to re-write the URL to drop the 'https' in favor of 'http'. The head

end of our tunnels must have https at all times and our basic fix-ups can't

detect browser JavaScript coded changes.

As we bring on-line new devices and newer versions of the firmware of

existing devices, we are advocating for changes to make them compatible with

the VAR PORTAL cross launch feature. As with any large company, it does take

time and with Thunderbolt getting into a larger trial and garnering larger

interest, we are having more success encouraging these future changes.

Robert

On 9/4/10 6:02 AM, "kurt.schumacher"

[Kurt Schumacher]

There are two issues then:

1. Curious, why the TBA does try to make use of https when not asked to...?!? No. ticking this ugly selection is _not_ required when connectig direct i.e. to https://nss324/  For simplicity, I decided to configure the Web UI access for http/8080, but not for https/443 - as we're in a more or less secured customer LAN. -> This is a TPA issue - something strange here.- when starting wiwth http://....:8080 is does remain on  http://....:8080.

2. Perfect - you discovered an issue on the NSS32x!  What works on the NSS32x OEM units - when connecting as https://ts-659pro/ the "SSL" is ticked automatically, so the redirect goes to https. Different on the Cisco NSS32x: It can be called directly to https://.....[:port] - but the "Use SSL" is not ticked automatically, so the redirect is switching from https to http, and the TPA proxy fails.

Who is reporting to Davin and Clint now?

Regards,

-Kurt.

[jamwyatt]

Kurt,

The ASCII art version of what our tunnel setup looks like:

Browser ---------------- VarPortal ------------------ Thunderbolt ---------------- NSS

              HTTPS                  SSL TUNNEL                       http

Some of these issues come from a complexity we've added, for security reasons. Unlike a simple port forward through a firewall (or proxy) (end to end same protocol like HTTP->HTTP or HTTPS->HTTPS), the VAR portal accepts only SSL connections, in the interest of security, which is then securely tunneled to the Thunderbolt. Several lan side devices, like printers, only support non-SSL connections. When the connection comes out of the other side of the tunnel, on the LAN side, the content is either HTTPS or HTTP (based on connection settings chosen in the VAR Portal configuration). Most people should be allowed to continue to use HTTP, even though they see an https:// in their browser (efficiency). Due to this protocol shift, we get different devices changing the protocol and/or port. Either of these changes that are built from Browser side of the connect, will cause an issue. We do try to catch any explicit non-relative URL changes with the options on the web connect page, but there are situations we can not correct.

In the case of the NSS, the use of the check box thwarts the conversion to https in the URL, and operations continue on with port 8080, non-SSL, without an issue.

I'll talk to Clint and Davin so that they are aware of the issue. I believe that this is a feature of the NSS and we might not find a quick or simple solution to make this better in the short term. I know the NSS32X product line is very popular and fixes are being screened very carefully based on 'value' and need. Especially fixes that might make functional changes.

Robert

[Kurt Schumacher]

No SSL, default Web admin UI port...:

[dcorley]

"Who is reporting to Davin and Clint now?"

Kurt, SBTG has over 400 legacy devices in the field. While Thunderbolt is not yet deployed as a production service, the internal drive towards that event is growing in its intensity. Accordingly, a TG-wide specification has been approved that starts the process of defining the device management behavior and interface with SBTG solution managers ... including Thunderbolt. Our concentration initially is on imminently released products. As an example product, the SG300 series small business managed switches take the first step toward interoperating with an SBTG solution manager in mind. Success in the managed services will acccelerate acceptance of the spec among our team members. Beyond SG3XX and its cousins, other future-facing products will follow. With 400 products in the "legacy" domain, picking and choosing which are at the top of the priority list for modification to the new spec will be daunting...as well as expensive. We'll look to you and other partners for guidance.

Thanks,

Dave

[Kurt Schumacher]

Hello Dave,

Convinced there is just a very minor issue making the NSS3xx web connection fail. I'll deal on this part for you with the NSS crew - already done half of it some hours ago.

Don't trust asking - you are mentioning SG 300 and the cousins (SF 300 or SG 200?). Have one of each installed and discovered by the first TBA in the environment here. I was under the impression, only ESW switches and WAP4410N WLAN AP are really in scope at that time, as we received demo samples. Somewhat cumbersome was the conversion of the US version samples to European standard (we were lucky, realized on hot to remove the power bricks from the TBA and had power cords available where required), but the WAP4410N is a -A PID, which does not allow to adjust the WLAN channels to European standards (generally 1..13, but less in France), while the -E offers also the US settings. Anybody over ther who can help us either convert the PID, or at least make a firmware available which offers the European WLAN channels.

We will bring up the other TBA up soon with the sample hardware provided in a dedicated VLAN, so we will have both a highly mixed and a plain Cisco SB network  The  we might consider to move SF 300 and SG 200 management IP to this VLAN, too. Both WAP4410N will follow, as soon as we can run these to European specs.

-Kurt.

[dcorley]

I think you are correct on the NSS320, Kurt.

For the SG3XX, we are not yet formally supporting the box yet. It will likely be in a few TB drops from now, though. Until then, only ESW5408P and WAP4410 are formally supported. Our collaborative work with the switch device team ensured that TB discovery agents were present on the new switches.

An issue you may encounter on the SF/SG300 is that cross-launch may be problematic. Pre-FCS SG3XX firmware included device admin GUI link references that were absolute rather than relative. We atempted to influence the design of the device admin UI to use relative addresses for the FCS device manager UI so that remote solution managers (Thunderbolt) could access and re-direct to other pages without knowledge of the absolute reference. I believe we were successful in influencing the web server design to allow us to use relative link references.

Concerning the WAP4410 RF issues, suggest contacting Ivor Diedrichs, the manager, product marketing. My memory is short, but I believe that the 4410 may not have a means to enable EU freqs and disable US and other wireless channels...whether through the shipping firmware or a European-specific firmware Ivor will know, though.

Dave

[Kurt Schumacher]

Would you mind sharing Ivor Diedrichs e-mail and phone number please?,

Looks like all 4410N make use of the same firmware, the PID makes it to offer different regions.

[dcorley]

Hi, Kurt.

Ivor Diedrichs

idiedric@cisco.com

+1 949-823-1547

Ivor is the manager of product management for Cisco wired switches and wireless access points. He is located in Irvine, California... just outside Los Angeles in the Pacific Daylight Savings time zone.

Thanks,

Dave

[Kurt Schumacher]

Wild guess - after clicking on "Connect", the dedicated browser pop-upi...

Browser -> https (virtual ciscovar.com server),tunneled into ssl - ssl in ssl tunnel over the Internet -> tunnel terminated on the TBA -> NSS32x

[jamwyatt]

Sorry about the truncated previous post ... that will teach me for trying my hand at simple ASCII art.

Anyway, I hope that the edited version makes more sense. Your assessment of what is happening is roughly correct. As explained the edited post, we cause an odd shift in the protocol from https to http, in most cases, through the tunnel. When this is the case, devices like the NSS32X can cause browser side programatic re-writes of the URL that can thwart the tunnel's best efforts.

To clarify your image uploads, the 'Use SSL' to be checked is on the login page of the NSS32X. The Connection Tab on the VAR Portal should contain port 8080 and not select 'Secure (HTTPS) connection'. The later causes a more traditional https -> https like connection, but it costs performance on the receiving device (and some don't support https).

Robert

[Kurt Schumacher]

Hi Robert,

Thia all makes perfect sense! Fully understand the design, almost at least, there is no rocket science included. But a lot of time and resources already to bring it to the reliability we already see today.

Any random "normal" Web application should work smoothly over this tunnel, so does the OEM NAS Web UI - but not the NSS32x one. Time and fun permitting, I'll dig inside this part later, and let the NSS3xx crew know. As you have seen form the NSS324 firmware version, we're well integrated into the next feature phase for NSS3xx.

Keep going! We appreciate all efforts.

-Kurt.