http to https web access

If I understand you correctly, you need port 80 (HTTP) on the client side and port 443 (HTTPS) on the server side. If that's it, then you may need to simply apply a server SSL profile to the virtual server. The VIP will listen on port 80 and forward to pool members on port 443 with an associated server SSL profile to handle the backend SSL negotiation.

I have this configured but it's not working. it goes to page cannot be displayed after about 2 minutes of trying to open.

 

 

could you please share any article that you know that has the steps to follow to get this working?

 

 

Thanks

 

The LTM configuration guides are your best source for instructions on setting up client and/or server SSL profiles.

 

 

Let's start at the beginning though with the assumption, if I understood you correctly, that the client contacts and maintains a session to the BIG-IP on port 80 (HTTP), while the BIG-IP contacts and maintains a session to the pool members on port 443 (HTTPS). So while the servers themselves are listening on an https:// address, the client is always using an http:// address. If that is so:

 

 

1. Standard LTM virtual server (HTTP profile, SNAT profile as required, pool of port 443 servers, OneConnect profile, and anything else you may need)

 

 

2. Server SSL profile - I'm also making the assumption that the server does NOT require a client certificate. If so, you can simply apply the built-in generic serverssl profile to the above virtual server.

 

 

This configuration will very simply translate port 80 client requests to port 443 HTTPS requests to the server(s). In the event that this still doesn't work:

 

 

1. Open a connection to the BIG-IP management shell. Run a tail of the ltm log (tail -f /var/log/ltm) and try the connection again.

 

 

2. If you see a log entry to the effect: "Connection attempt to insecure SSL server (see RFC5746): :", then you're server does not support secure renegotiation. Create a new server SSL profile, set Secure Renegotiation to "Request", and then apply this new server SSL profile to the above virtual server (replacing the built-in serverssl profile).

 

 

3. If it still doesn't work, or you're not seeing the above message, try to capture the HTTP dialog at the client (WireShark, HTTPWatch, Fiddler2, etc.). Look for references (30x redirects, embedded objects, links, etc.) that point to HTTPS://. If you see any of these, then you'll need to use a stream profile and a simple iRule to capture and transform these back to HTTP:// in the response flow.

 

 

4. If you don't see HTTPS:// references, then the next step would be to do an SSLDUMP on the server side of the BIG-IP to see if the SSL is actually negotiating successfully.

 

Kevin,

 

 

I really appreciate you taking the time helping out.

 

 

I'll try your instructions and report back hopefully today if not, thn Monday.

 

 

Thanks a lot

Kevin,

 

 

I tried this all the way to having fiddler running and saw that it had 30x redirect, so could you please help me with the streaming profile and the iRule?

 

 

 

Thanks

 

If it just has 30x redirects, then you only need to apply Redirect Rewrite Matching in your HTTP profile.

The stream iRule is only necessary if the application is sending links (not redirects) back the client with http:// in the URL. If you still need the stream, add the default stream profile to your virtual server and add this iRule (tweak as required):

 Example which replaces http:// with https:// in response content
 Also prevents server compression in responses
when HTTP_REQUEST {
     Disable the stream filter for all requests
    STREAM::disable
    
     LTM does not decompress response content, so if the server has compression enabled
     and it cannot be disabled on the server, we can prevent the server from sending
     a compressed response by removing the compression offerings from the client
    HTTP::header remove "Accept-Encoding"
} 
when HTTP_RESPONSE {
     Check if response type is text
    if { [HTTP::header value Content-Type] contains "text" } {

         Replace http:// with https://
        STREAM::expression {@http://@https://@}

         Enable the stream filter for this response only
        STREAM::enable
    }
} 

Kevin,

 

 

I tried this and got Internet Explorer cannot display the webpage. if I have fiddler running, I get the message of [Fiddler] ReadResponse() failed: The server did not return a response for this request.

 

 

I really don't mean to trouble you with this, so I am going to create a support case with F5 and see if they can help.

 

 

Thanks a lot for all you've done.

 

 

MJ

No worries MJ.

 

 

Does it only fail with the iRule applied?

 

 

After you apply the iRule, open a "tail" of the LTM log at the BIG-IP shell command line: tail -f /var/log/ltm

 

Try the test again and see if the log reports anything. The iRule is mostly harmless but you may have some formatting issues from the copy and paste.

 

 

One more thing:

 

I tried this all the way to having fiddler running and saw that it had 30x redirect

 

 

If it truly is JUST a 30x redirect, then you don't need the iRule. Just enable Redirect Rewrite in the VIP's HTTP profile. The "matching" setting usually works, but you can also try "all".

 

Hi MJ,

 

 

The problem I see is that your application/web server is making the calls to a Web Service which requires HTTPS. The question is....how is the Web Service configured?

 

 

So here are my questions

 

Is this HTTPS Only Web Service configured to run through a Virtual Server? Is it the same BIG-IP that the HTTP Only Application is using?

 

or

 

Does the HTTPS Only Web Service even have a Virtual Server on the BIG-IP?

 

 

This is why I ask each question:

 

Is this HTTPS Only Web Service configured to run through a Virtual Server? Is it the same BIG-IP that the HTTP Only Application is using?

 

If so, then configure the HTTP Virtual Server for the Web Service to detect where the incoming request is coming from (there are several ways to do this). If it is coming from the HTTP Only Application, Enable your SSL Profile (Server) on the HTTP Virtual Server and let it talk (basically what Kevin was suggesting with a Twist). If it is not coming from your HTTP Only Application do an HTTP to HTTPS Redirect. This will allow your problem child to talk to the Web Service but nobody else (everyone else will need to use HTTPS).

 

 

Does the HTTPS Only Web Service even have a Virtual Server on the BIG-IP?

 

If not then you have a whole new problem. Communication is happening between the HTTP Only Application, directly to the HTTPS Web Service (bypassing the BIG-IP). Since the BIG-IP is an event driven system it is not going to capture the initiated Web Service Call by your HTTP Only Application (Well, it could but you'd really have to dive down deeper than you'd ever want to go to get it). If this is the case I would suggest configuring a Virtual Server for your HTTPS Web Service (even if this is the only application that uses it) and configure your application to use it.

 

 

Hope this helps.

Kevin,

 

 

I apologize for the delay in posting back. I also want to thank you so much for your help and wanted to know that it's all working now.

 

 

to be specific the solution you posted in 03/07/2013 10:58 AM was correct, and the only difference here is the web server that I was connecting to, because that other one seems to have its own problems, so I tried another one and the next thing you know it's working fine.

 

 

here's what I followed from your post:

 

Let's start at the beginning though with the assumption, if I understood you correctly, that the client contacts and maintains a session to the BIG-IP on port 80 (HTTP), while the BIG-IP contacts and maintains a session to the pool members on port 443 (HTTPS). So while the servers themselves are listening on an https:// address, the client is always using an http:// address. If that is so:

 

 

1. Standard LTM virtual server (HTTP profile, SNAT profile as required, pool of port 443 servers, OneConnect profile, and anything else you may need)

 

2. Server SSL profile - I'm also making the assumption that the server does NOT require a client certificate. If so, you can simply apply the built-in generic serverssl profile to the above virtual server.

 

 

Again thanks a lot.

 

 

MJ