This is possible.. I just did a similar thing at a customer site not so long ago. You'll need two route domains, one externally facing and one internally facing. The external route-domain has a VS with the client-ssl profile to decrypt the packet. This virtual server is tied to a pool with a member that is the IP address of a second VS that exists on the Internal route-domain. The VS on the Internal side has no client-ssl profile, but has a server SSL profile (if you want to re-encrypt..) and is tied to a pool of the resource that you'd actually like to hit.
As an example, external route-domain would be defined at %10 and your internal route-domain would be %20. External IP 192.168.10.10 and the Internal networks would be in the 10.10.10.0/24 space. Using these networks and route domains, you'd have something like:
external_vs - 192.168.10.10%10 on port 443
external_pool - 10.10.10.100%10 on port 80
internal_vs - 10.10.10.100%20 on port 80
internal_pool - 10.10.10.50%20 on port 443
Doing something like that and putting an L2 IPS/IDP/packet counter sniffer thingy on the wire between the External_pool and the Internal_vs, you end up getting a good solid look at anything that might pass through.
Couple of notes:
- You'll obviously need self ip's for the appropriate networks in each route-domain.
- SNAT is your friend.
- By using overlapping space between internal/external route domains, you save yourself some routing work. It could certainly be accomplished using separate networks, but your routing table gets a little more complex.
- I'm writing this from memory, so I'm certain I've forgotten some critical detail that will make this fail. :-) I'll try to monitor this post and lend a hand as time permits.
Good luck.
-brent
Nimbostratus
