About jwaite

jwaite · ‎10-03-2013

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.

jwaite · ‎10-01-2013

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 · ‎10-01-2013

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.

jwaite · ‎09-30-2013

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.

Re: Publish RSA self-service console via Stingray ...

Re: Re: Publish RSA self-service console via Sting...

Re: Publish RSA self-service console via Stingray ...

Publish RSA self-service console via Stingray ?