In article , wrote: :I found this example but the subnets on the access lists are different, :so i dont think it applies and i bet it wont work with loadbalancing.
:how ever may be for fault toulerance, I can add a second peer to the :pix in the same crypto map right?
You can add something like 6 peers to the same crypto map policy clause. Those are for fault tolerance only.
Anything beyond that would have to be handled at a stage before. For example, if you had a router inside the PIX perimeter that did policy based routing such that any one flow was always routed the same way, and at the LAN router you were to NAT the different policy outlets seperately, then as far as the PIX would be concerned they would be different inside hosts and the PIX would be able to run them through different VPN tunnels.
You can also do -some- of that directly on the PIX, by using a combination of policy NAT and multiple crypto map policies. The crypto map match-address ACLs are not looked at until -after- NAT has taken place, so if you can express your different streams in terms of diferent layer 4 policies that can be source NAT'd to different IPs then the crypto map could be specific to the different post-NAT'd sources and so send them through different tunnels. But at least in PIX 6.x, you cannot split a single flow over multiple outlets -- per packet load balancing from within PIX 6.x is Right Out for TCP [UDP... might be hackable, icmp not.]