http to https web access

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.