client and server ssl profile

This is often called SSL Bridging - ie traffic comes in from client as SSL and goes back out to server as SSL. To do this you just add a client-SSL profile ( with an appropriate certificate/key ) and a server-SSL profile. Obviously you need to ensure the pool member is pointing at the SSL port such as 443.

Yes it is possible and allows end to end encryption, with the only decyption being on the BigIP.

You create the clientssl profile for client to BigIP connections and assign it to the Virtul Server.

You create the serverssl profile for BigIP to server connections and assign that to the Virtual Server.

Dear friends I have configured self signed certificate both side and web servers are pointing also on port 443

when i was calling vertual server i have to accept certificate but after installing it i can not see the web page. What could be the possible reason

You can actually just use the built-in serverssl profile on the server side. There's usually no need to define any certificates in the server side connection. Also, depending on your web server's ability to handle secure renegotiations, you may need to switch to the serverssl-insecure-compatible profile. You should errors in the LTM log if this is the case. So just to level set:

1. LTM VIP listening on port 443
2. Client SSL profile
3. Server SSL profile
4. Pool pointing to port 443 servers

As Pete states, this is referred to as "SSL bridging". If you completely remove the SSL profiles, where the client and server perform a direct SSL handshake across the F5, this is often referred to as "SSL tunneling". It may be a worthwhile test to see if SSL tunneling actually works. If it does, then re-apply the client and server SSL profiles and take a look at the traffic on either side of the F5. Do you see any traffic on the server side (SSL or otherwise) when it fails? If you don't, that's usually an indication that client side SSL is failing. If you do, then the problem is likely on the server side. One of the best tools to examine this traffic in detail is ssldump. Fire that up from the command line and watch the actual SSL handshake between the client and F5, and between the F5 and server.

ssldump -k [path to private key] -i 0.0 -AdNn port 443 [and any additional filters]

The private key on the client side will be the private key assigned to the client SSL profile. The private key on the server side will be the private key assigned to the web server. If this it an SSL handshake error, it should make itself evident in one of these captures.