Clone Pools can be configured to capture one way or two way traffic (Traffic to the Server from the Client - Clone Pool (Client) and traffic to the Client from the Server - Clone Pool (Server)). It does this during SSL tear down if the traffic is encrypted.
Another interesting option I have seen tested to solve this issue actually involves using 2 different route domains on the LTM. Basically there is a front side route domain and a back side route domain with the IPS in the middle processing traffic transparently.
Here is an exampl
Route Domain 1 Transparent Route Domain 2
VS(22.214.171.124)clientSSL --> Pool(192.168.100.100 and 192.168.100.101) --> IPS --> VS(forwarding VS)w/serverSSL
Traffic passes through the VS in RD1 and is decrypted with a client SSL profile and sent to pool members in the clear. In order to reach the pool it has to exit the interface in the 192.168.100.0(RD1) vlan which is directly connected to the IPS. The IPS is then connected to a l2 only VLAN in RD2. This VLAN is set to bridge all traffic to the 192.168.100(RD2) vlan which has a forwarding VS that has a server SSL profile applied to re-encrypt to the back end.
This is somewhat simplified version of it and I may not be explaining it perfectly but it would do the job for sure. Clone pools may be an easier option if they work in you situation.
The problem with clone pools is that they require the IPS to actually be targeted in some way with an IP and MAC address. Many inline IPS deployments are completely transparent and there's nothing to target at L2/3. You're doing SSL offload to a ghost. This leads to the config mentioned by Steve which I have had the unfornuate experience of dealing with at length. It works but is a very complex setup. RD's are required b/c you'r processing the same traffic 2x targeting the same L2/L3 address space.