SSL client to f5 and f5 to websever

• Both the virtual server and pool members are required to process SSL connections, and the BIG-IP system is required to perform Layer 7 processing, such as iRule or cookie persistence.

In this scenario, the virtual server must be configured to perform SSL decryption and re-encryption. Configure a standard virtual server and associate Client SSL and Server SSL profiles with the virtual server.

sol12015: Configuration requirements for SSL virtual servers, profiles, pools, and monitors

• Both the virtual server and pool members are required to process SSL connections, and the BIG-IP system is required to perform Layer 7 processing, such as iRule or cookie persistence.

In this scenario, the virtual server must be configured to perform SSL decryption and re-encryption. Configure a standard virtual server and associate Client SSL and Server SSL profiles with the virtual server.

sol12015: Configuration requirements for SSL virtual servers, profiles, pools, and monitors

I standard VS which is load balance between IBM WebSeal on SSL. I am not able to access node on SSL through this VS.

have you tried ssldump? what did you find?

sol10209: Overview of packet tracing with the ssldump utility

If I may add a few thoughts:

1. It doesn't appear that you have a server SSL profile applied to the VIP. In order to perform this "SSL bridging", you need a client SSL profile to first terminate the client side SSL, and then a server SSL profile to re-encrypt to the web server.

    

2. If it's still not working, I would FIRST look at where it's failing. Because you're dealing with a full proxy here, if you TCPDUMP on either interfaces (client side or server side) you should see where the traffic is failing. For example, if client side SSL is failing, you shouldn't see traffic on the server side.

    

3. Once you've determined where the problem is, you can then start looking at why it's failing. For this you can use a tool like SSLDUMP. It will generally, and not always intuitively, show you what's going on inside the SSL handshake, and will (sometimes) point right to the problem.

    

Your config looks essentially correct, so the first thing I'd do is determine where it's failing.

tcpdump -lnni 0.0 host x.x.x.x

where x.x.x.x is the VIP's destination address. This will show the client side traffic. You could also specify the VLAN name for the -i (example: -i internal_vlan). The 0.0 name catches all traffic, so you need to be specific with the filter. You should definitely see this client side traffic. Now run the same command using the IP address of the web server as the filter.

tcpdump -lnni 0.0 host y.y.y.y

If you see any traffic from your client to the web server, then you can reasonably suspect that the issue lies on the server side of the proxy. The next step would be to fire up the SSLDUMP and see what may be going on inside the SSL handshake:

ssldump -k  -i 0.0 -AdNn port 443 and host y.y.y.y

where:

-k  = the physical path to the private key used by the web server. You may not have this private key on the BIG-IP, so you'll need to upload it somewhere.

-i 0.0 = all interfaces

-AdNn = a set of options that specify to decrypt the traffic if possible (and to simplify the output)

port 443 and host y.y.y.y = unlike TCPDUMP, the SSLDUMP must have a filter. Here we're specifying that we want to listen for port 443 traffic to/from the web server's IP address

You can certainly upload that SSLDUMP here for the group the analyze, but if the capture otherwise looks normal, then I'd next start working up the stack. I notice that you have an iRule applied and I vaguely remember a discussion form another post that refers to this, but

1. Have you tested this VIP without the iRule?
2. Have you tested this VIP with the iRule but without SSL?

3. Do you see any errors in the LTM log?

   tail -f /var/log/ltm

In other words, given the error indication, a layer 7 problem can look just like a layer 6 or layer 4 problem. I'm always inclined to work from the bottom up, as more often than not the issues are network or SSL related, but you could certainly be experiencing an application layer problem.