datagroup value set to SSL?

if you want to do SSL you need client and / or server SSL profiles (depending on which side you want to do SSL).

you could extend your iRule to disable SSL when port 80 is used if needed.

thanks for the response. we since did away with the datagroup/irule, and are just having plain trouble load balancing with a regular pool. our flex app loads https ok outside the F5, but not through the F5. tried many combos of clientssl/serverssl/port translation/node on port 443/ combo i cank think of. we do have a case open with F5, and the SSL handshake is suspect in the trace, so hopefully we find something next week. we eventually want to use the F5 datagroups to steer traffic to local nodes based on hostname, but we gotta get over this hurdle first :-)

so i guess you have configured APM to listen on port 80 with no SSL client profile being attached.

When you terminate (and optionally re-encrypt) SSL at the F5, you're performing a full proxy on the SSL layer. The client side (client to F5) and server side (F5 to server) are separate SSL sessions. And as a security device, the F5 tends to be a bit less flexible than a client browser. For instance, if a client browser initiates an SSL session to a server, and that server doesn't support the latest-greatest crypto and/or TLS extensions, the browser will often dutifully downshift into what the server can support. One of the biggest issues I see with SSL bridging is when the server doesn't support TLS RFC5746 Secure Renegotiation. The default server SSL profile on an F5 is set to require this extension, so server side SSL will fail unless you set it to "Request". You'll actually see this error in the /var/log/ltm log. You may also want to, for troubleshooting, set SSL logging to debug. Most SSL-related errors will show up in the ltm log once you do that.

thanks Kevin and kunjan!

i did try turning on serverssl set to "Request", but that just gives me a page not found in the browser. no combination of any serverssl settings seem to load anything but "page not found"

i tried turning on ssl debug, and then loading the page, but the IP of my node didn't turn up in any of the handshake failures logged to /var/log/ltm.

i see this 500 error back from the app in fiddler when i try client ssl with the node on port 80 (this is where the page loads up, and shows the flash/flex menu if i right click, but the login page/app is never presented):

So, it does seem to me something about the F5 talking to the app server properly. i've been playing with the cipher strings on the client and server profiles as well, but havent' found a combo that works.

i see this unresolved devCentral question that seems related last update was 1 month ago: https://devcentral.f5.com/questions/ssl-offloading-not-working-as-expected

Will keep plugin away, reading the manual, dev central cases, and trying combos, fiddlers, traces, until we get something to bite :-) thanks much to all, Keith

Interesting. So if you do no (client side or server side) SSL, just port 80 on the VIP load balancing to port 80 pool members, I'm assuming that doesn't work, correct? From the described error message it sounds like the application is expecting and requires that you talk to it over SSL. A 500 error means you're actually getting to the web server, so at the very least you need a server SSL profile and nodes on port 443 (or whatever SSL port they listen on). I'd start with the 'insecure_compatible' server SSL profile as it has the lowest set of requirements, and I'd also remove the HTTP profile until you have good data flow.

thanks again Kevin. the application is a flex and is compiled at install time to only work with SSL in mind. so, even if i hit http:// locally on the server, it does the same thing (flash settings on right click of an otherwise blue background blank page). it's some sort of security i imagine (to not show the login if SSL handshake isn't there). tried insecure_compatible serverssl profile with http profile set to none, and the node on port 443 in the pool, but it just shows "page cannot be displayed".

The only way i got it to work so far through the F5 is using complete passthrough (no client/serverssl or http profiles, and node on 443), but i need an irule to steer traffic, so i'm stuck tryin to figure it out i guess. :-) i'm trying to imagine what is happening is the F5 is using a different set of ciphers when talking to the apache coyote server and there is a handshake failure resulting in the flex app sending the traffic to http, and giving that 500 error. that's odd though, because debug mode didn't show any handshake failures.

Speaking with Gary on F5 case 1-1307326921 just before the start of the 4th break, we took a trace using this command: tcpdump -ni 0.0:nnn -s0 -e host 10.33.225.20 and port 443 -w sslcap.pcap

And he also said he sees handshake failures in the trace. So, maybe they are a different breed of handshake failures that are eluding debug mode? i'll keep digging :-)

I guess what's most troubling to me is the 500 error. That's coming from the application. You wouldn't get that error if SSL issues were breaking the connection. At this point I would probably do a Fiddler capture with SSL tunneling enabled, and then again with SSL bridging and compare the two. You can also do an SSLDUMP on either side of the proxy:

ssldump -AdNn -i 0.0 port 443 and host [VIP address for client side traffic and server IP for server side traffic] 

This will show you the cleartext portion of the SSL handshakes and if there are any errors, that's where they'd be. Also do this capture for a tunneled connection in case there's some issue with the bridged server SSL handshake that's causing the problem. Look at the ciphers negotiated and any TLS extensions that are in one but not the other. Believe it or not I've seen applications choke because there was no Server Name Indication (SNI) value coming from the server side SSL.

ok, here goes, hoping the formatting comes out ok. the first block is broken http. profile+client/serverssl+node.on.443. the second block working passthrough is no http.profile no client/serverssl, node on 443. tried a third attempt with just http.profile+client ssl, but nothing showed up in the ssldump command at all (i think that is expected since the web server is telling us we're not secure).

There are a ton of cipher differences, and the broken one has some smoking gun sounding phrases like "Not enough data", and "Fatal" :-)

thanks Keith

ok, wow, i'm excited! after probably 8 hours a day since wednesday looking at this, a solution arrives. turns out the developers had a directive called SSLVerifyClient value in the server.xml file for the server's coyote tomcat server config. I had to set it to "none" , and restart the application to finalize the change. the from --> to output is below.

Now, i'm finally using http.profile+clientssl+serverssl(regular)+irule.datagroup.node:443 and loving every minute of it!

Thanks much to everyone involved! time to get some rest, and enjoy what's left of my July 4th vacation.

🙂

-Keith

. server.xml from:

server.xml to: