Publish RSA self-service console via Stingray ?

[jwaite]

First time post and reasonably new to STM so hoping someone can assist...

Has anyone successfully published the RSA self-service console via Stingray Traffic Manager ? I'm having no luck at all and the configurations for other platforms (TMG, ISA, NetScaler) don't appear to work on STM.

The internal server publishes a site at https://<internal FQDN>:7004/console-selfservice/ which works fine. I have a pair of STM virtual appliances in the DMZ network where I'm attempting to publish this from for external users. A web browser in the DMZ added to the object group for the rule allowing TCP/7004 can access the site fine.

If I don't enable SSL decrypt and simply load-balance the external 7004 service to the internal server I get a SSL connection error on the client (presumably due to the cookie/Location not matching the internal FQDN).

If I enable SSL decrypt and set the appropriate host header fields, cookie domain and Location to match what an internal user would have I get a 'Service Unavailable' screen back from the RSA server. I've tried this with and without rules to rewrite host headers (Request) and body content (Response) to replace the internal FQDN with the external one.

Hoping that someone has done this before and has an easy(ish) way to configure this or some ideas about what may be going wrong / how to troubleshoot.

Many thanks in advance.

[markbod]

Hi Jon,

You don't mention it, but when you enabled the SSL decrypt on the Virtual Server, did you enable SSL encryption on the pool? If the "Service Unavailable" message is in Red, then it's likely the default error page from Stingray. If you are not re-encrypting on the pool then Stingray will be trying to talk HTTP to a HTTPS service resulting in service failure.

Cheers,

Mark

[jwaite]

Hi Mark,

Just checked (since I've made quite a few changes to the service & pool attempting to get this working), and yes SSL encrypt is set for the pool. The Service Unavailable message is in red so appears to be coming from the STM and not the backend server as I thought. The standard HTTPS monitor doesn't work against the node, but using a generic TCP connection monitor against the port works (so the port is open and firewall allows the traffic). Even with no monitors running I still get the 'Service Unavailable' screen though. The connection log shows a 500 error against the GET request from the backend node whether or not SSL encrypt is enabled.

[markbod]

Hi Jon,

If the RSA server is returning a 500 then it's obviously not liking the request we're sending. Do you still get a 500 when you request "/console-selfservice", and are you rewriting the host name to match the node? I presume you only have one active node in the configuration, because other docs suggest that only one server can be written to at a time. You should have a pool with the primary in it, and a secondary pool with the backup. The secondary pool should be set as a failure pool of the primary.

some other pointers which may help

• You don't need a rule to rewrite the cookie. Remove it. Instead go to Services -> Virtual Servers -> Your VServer -> Connection Settings -> Cookie Settings and set "cookie!domain" to "rewrite the domain to the host header in the request".

• You also don't need to worry about rewriting redirects. Still under Connection Settings look at "Location Header Settings" and for "location!rewrite" select "Rewrite the hostname to the requests host....."

• In order to ensure you are setting the correct hostname when you switch to the backup you can use pool.getActiveNodes() to determine if the primary pool has failed and start setting the hostname to the secondary when it does.

You may be able to determine whether a request is a read or write and route to primary or secondary based on the request type, but that would require further investigation.

If you still can't get this running, then you may want to contact your Riverbed account manager about getting assistance from PS.

Cheers,

Mark

[jwaite]

Hi Mark,

Have tried all the settings you suggest without success, I think I'm going to have to log a PS call. I've found guides on the web for other LB platforms (e.g. NetScaler here Publish RSA Self-Service Console through NetScaler | Blog | Henny Louwers ) but can't see anything in these steps that would be different or prevent the site working via Stingray Traffic Manager.

Many thanks for your help, Jon.

[jwaite · Accepted solution]

Just to update this, Riverbed support (Andrey) have been fantastic and I now have a resolution for this issue.

The root cause is downlevel TLS/SSL support (and the order in which negotiation is attempted) in the Riverbed RSA web server that I was attempting to load balance which means the SSL handshake negotiation for the Node fails. If anyone suspects they have the same issue they can try disabling all SSL settings under Global/SSL except ssl!support_tls1.

Obviously globally forcing everything back to TLS 1.0 isn't ideal so Riverbed have given me a workaround, but I'm not sure if they would want this posted generally.

Huge thanks to Mark Boddington here and Andrey Chernyak from Riverbed support for their assistance with this.