we are trying (from questions brought up during our most recent PCI compilance exercise) to set up the following.

Apache2/WLPlugin <-SSL-> F5 9.4.8LTM  <-SSL-> Oracle/BEA Weblogic server 10.0 MP1

after much wailing and gnashing of teeth I have it working as

Apache2/WLPlugin <-SSL-> Oracle/BEA Weblogic server 10.0 MP1

once we plug the F5 in the middle the weblogic plugin cannot communicate with the weblogic server.

the conjecture is that we need to terminate the SSL on the F5 and re-encrypt for the trip to Weblogic Server. 

we have never attempted this before and since this is not a critical production issue,  I get to try to figure it out.  I have almost no knowledge of F5 configuration so would greatly appreciate any pointers!  especially if this is or is not possible.

Something else I figured I'd throw in, currently we have a cluster of webservers behind an F5 in DMZA, communicating using the weblogic plugin through a F5 to a cluster of weblogic 10.0MP1 app servers in DMZB.


This configuration works fine, it breaks as we try to switch to SSL communications.

Can you elaborate more on "weblogic plugin cannot communicate with the weblogic server?" This sounds like a simple network issue -

Also, when you say it "breaks" when you try to switch to SSL communications - are you seeing WebLogic send http redirects instead of https? You can simply insert a header so WL thinks communications are SSL and it won't send http redirects back.

Chris,

I think you might have the answer to an issue I am having. We run Oracle EBS and Discoverer behind an F5 load balancer. We let the F5 handle the https/ssl up front. Connections to the application servers are http on the back end. We are working on an upgrade of Discoverer (a J2EE-based Oracle reporting tool as I understand it). The older version used to run on Oracle Internet Application Server (iAS) but the new "Fusion" version runs on WebLogic Server. While load balancing works for the older stuff we're having an issue with the WebLogic stuff that I would have thought was easy to resolve. It seems simple to me...the Discoverer application is generating URL's with the address http://external-server-name:80/ when we need it to return https://external-server-name:443/ (even though SSL is being terminated at the F5 and WebLogic gets the requsts over http://back-end-host:8888/.

I figure there must be some simple override setting somewhere in WebLogic Server that says "I don't care what protocol and port you are listenning on....when an App asks you what our URL is say https://external-server-name:443/".

I found your answer intruiging though about inserting a header? What header can be inserted that the WebLogic Server will then override the protocol and port information that it gives to apps running under it?

I've actually set up an Apache web server as a load balancer instead of the F5 (mostly because I don't administer the F5's so I had more options) and the same thing happenned, but I did notice that Apache was forwarding X-Forwarded-By headers or something like that in the requests it would proxy to the back-end server. Those headers didn't seem to have any influence over the WebLogic Server's headers though.

I admit I am brand new to WebLogic server. But, I have administered Apache and Tomcat servers before and have tinkered with iAS. I have done some searching around in the WebLogic web-based administration pages but haven't seen any overrides for protocol. I've been scanning through a lot of online forums and documentation so I promise I''m not just throwing this out there without doing some of my own legwork. I would have thought this would be a very easy configuration change but for some reason it doesn't seem like a very popular question to address online. Any assistance or pointers folks can provide with regards to ways to override WebLogic's protocol and port URL information it gives to J2EE apps (I'm guessing Discoverer is using the ServletRequest.getScheme() and ServletRequest.getServerPort() API calls) would be much appreciated.

Thanks,

Eric

Eric,

Here's a solution article for you:

http://support.f5.com/kb/en-us/solutions/public/4000/400/sol4443.html?sr=10058313

Simply create an HTTP profile named something like "WL-Proxy-SSL" and under "Request Header Insert" - type "WL-Proxy-SSL: true"

Then, apply that profile to your SSL Virtual Server.

Please forgive my ignorance Chris,

If I understand this properly...

1. The HTTP profile you are talking about setting up is in the F5 load balancer? Sorry, it's our network guys that usually
tweak the F5 side so I rarely have a chance to look at the configuration. But, I assume that we can make the F5 load
balancer insert a random HTTP header and value into the request before forwarding it and it sounds like that is what you
are suggesting. We modify the F5 policy so that it inserts a hard-coded header "WL-Proxy-SSL" and value "true" combination
into every request. But it sounds like the way it works in the F5 is to create a profile that encapsulates this action of
setting the header which must then be applied to the specific F5 virtual server in step 2.

2. At this point I'm unclear, are we setting up a virtual host on the WebLogic Server side, or do you mean we apply the
F5 profile to this particular F5 virtual server that we want to insert this new header? I think you mean the later of the two.

So at this point we would essentially have every incomming request that comes through this virtual server on the F5 getting
a constant header of "WL-Proxy-SSL: true" added toit.

Are you therefore saying that this particular header "WL-Proxy-SSL" has special meaning to WebLogic Server? When it sees
that HTTP header it knows to override the protocol/scheme from http to https?

I greatly appreciate your assistance Chris. If it really is as simple as adding a static header to every incoming request that
goes through the F5 then you have really made my day.

Chris,

I just did a quick web search on WL-Proxy-SSL and I'm feeling pretty optimistic here. I've seen several online forum posts
that talk about this approach. Why haven't I seen (or maybe just noticed) this in any of the official documentation I have
scanned through? I may have wasted a great deal more time were it not for your post. I'm off to go experiment.

Thanks,

Eric R.

Chris,

You solved my problem right there. Setting the WL-Proxy-SSL HTTP request header in the F5 did the trick. We
have it deployed now in our QA environment and our well on our way to hitting our deadline. Now the Discoverer
application (running in WebLogic server) is generating https URL's as it should.

You should know I searched every one of the following documents (which pretty much makes up Oracle's official
documentation for Discoverer, WebLogic, and related Fusion Middleware documentation). There's not one mention
of the WL-Proxy-SSL setting in any of the following documents.

• Oracle Fusion Middleware – Configuration Guide for Oracle Business Intelligence Discoverer 11g Release 1 (11.1.1): No
• Oracle Fusion Middleware – 2 Day Administration Guide 11g Release 1 (11.1.1): No
• Oracle Fusion Middleware – Concepts Guide 11g Release 1 (11.1.1): No
• Oracle Fusion Middleware – Administrator’s Guide 11g Release 1 (11.1.1): No
• Oracle Fusion Middleware – Installation Guide for Oracle Web Tier 11g Release 1 (11.1.1): No
• Oracle Fusion Middleware – Installation Guide for Oracle Portal, Forms, Reports and Discoverer 11g Release 1 (11.1.1): No
• Oracle Fusion Middleware – Information Roadmap for Oracle WebLogic Server 11g Release 1 (10.3.3) (“Getting Started Guide”): No
• Oracle Fusion Middleware – Installation Guide for Oracle WebLogic Server 11g Release 1 (10.3.3): No
• Oracle Fusion Middleware – Introduction to Oracle WebLogic Server 11g Release 1 (10.3.3): No
• Oracle Fusion Middleware – Configuring Server Environments for Oracle WebLogic Server 11g Release 1 (10.3.3): No
• Oracle Fusion Middleware – Using Clusters for Oracle WebLogic Server 11g Release 1 (10.3.3): No
• Oracle Fusion Middleware – Command Reference for Oracle WebLogic Server 11g Release 1 (10.3.3): No
• Oracle Fusion Middleware – Upgrade Guide for Oracle WebLogic Server 11g Release 1 (10.3.3): No
• My Oracle Support (Metalink) Note 858748.1: Oracle Fusion Middleware 11g - Getting Started FAQ: No
• Load Balancing BEA WebLogic Servers with F5 Networks BIG-IP: No
• BEA WebLogic Server – Configuring and Managing WebLogic Server 8.1: No
• Oracle Fusion Middleware – WebLogic Tuxedo Connector Administration Guide for Oracle WebLogic Server 11g Release 1 (10.3.3): No

I have two open SR's for this issue with Oracle: one for the Discoverer product (about two weeks) and a second with
the Oracle HTTP Server product (a few days). I had asked them to actually open the second support request with the
WebLogic Server product team but they were convinced apparently that it was the help of the Oracle HTTP Server
team that I required. I still figure had I actually gotten to the WebLogic Server product team that they would have
been able to help me with relative ease. Only after you gave me the actual header name WL-Proxy-SSL was I able to
go find a couple Metalink notes that reference it.

You helped us avoid missing our deadline and we greatly appreciate it. Thanks.

Just out of curiosity, how did you know about this setting? I cannot find it anywhere in the Oracle WebLogic documentation and I just used their own search engine to do the search. It would be nice to know where this is documented.

I knew about it from searching F5's docs...not from Oracle's. Since there are many different configurations that would require offloading SSL in front of WebLogic, I agree that the documentation should be better.

Hi,

I was wondering if you have some kind of similar idea for SSL server profile while having Apache server behind BigIP listening to SSL traffic. I am struggling with that for a weeks.

Any help will be appreciated.

PS.

I have tried above solution.

This setup des not work :

Client (SSL) ---> BigIP (SSL client and server) ---> Apache server (SSL)

This setup works:

Client (HTTP) ---> BigIP (SSL server) ---> Apache server (SSL)

Best regards,
Bart

Hi Bart, your first config is called SSL decrypt / re-encrypt, and is quite common with big-ip. You will need to use both the Client SSL and Server SSL Profiles on your virtual server.
There is some good info on how big-ip handles SSL traffic here: http://support.f5.com/kb/en-us/solutions/public/12000/000/sol12015.html?sr=10905129

When you say "does not work", can you clarify - no TCP connection, no/bad ssl handshake, ssl cert error, other ? Have you looked at the traffic with any tools - httpwatch, fiddler, etc ?

-Chris.

Hi Chris,

Thanks for reply and sorry for late come back. I found my solution. What I forgot to mention was that I was using LTM VE trial version of the BigIP. The thing is that as usual I forgot simple rule "read the manual"  but let's get to the point. With this version Client-Server SSL does not work "out of a box" just like you would configure it on the hardware platform (found here http://support.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnotes_ve_10_1_0.html):

ClientSSL and ServerSSL profiles on same virtual server (CR141545)
When you assign both a ClientSSL and a ServerSSL profile to the same virtual server, the BIG-IP system forwards the client request successfully, but the client does not receive the response. To work around this issue, you can create two separate virtual servers that specify the same destination IP address and port. The first virtual server references the ClientSSL profile and an iRule that internally routes the connection to the second virtual server instead of to a load balancing pool. The second virtual server references the ServerSSL profile and the load balancing pool. The following is an example of an iRule assigned to a ClientSSL virtual server. The iRule includes the virtual command, which internally routes connections to a second virtual server named server_ssl_test. The second virtual server must have its VLAN disabled using the vlan none enable command:

rule target_server_ssl {
 when CLIENT_ACCEPTED {
  virtual server_ssl_test
 }
}
pool b68_https { member 10.1.1.68:4443 }
virtual client_ssl_test {
 destination 10.1.1.117:443
 profile http clientssl tcp
 rule target_server_ssl
}
virtual server_ssl_test {
 destination 10.1.1.117:443
 profile http serverssl tcp
 pool b68_https
 vlan none enable
}
 

iRule support with the COMPAT stack (ID 247635)
Regardless of the validity of the client certificate, the iRule call SSL::verify_results will report success in BIG-IP Virtual Edition Trial.

Anyway thanks for reply. My problem is solved and above solution works .