SSL decryption to IDS

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