2010/10/27 Tom Devries <[email protected]> > Indeed, the only issue I see with policy based vpn's is the number of vpn > policies required for the amount of networks that have to be encrypted. As > someone pointed out on another list, the C device should support null proxy > ids if you first deny all other networks and then specify "any any" as > interesting. > > Policy based VPN is a really clumsy way when it comes to reservation. E. g. you need two tunnels and a mechanism to switch them in case of a failure. ScreenOS has vpn grups for this case, hope JUNOS Voyajer also does, but AFAIR it does not support more than two tunnels in a group and not really flexible overall.
Route based way is by far more flexible and scalable. Nathan gave the right clue: Cisco also can do route based either with VTI or using GRE over IPSec. BTW that proxy-id is a really silly thing. Why should I know in advance and configure statically which traffic I am going to transmit across a link? Just imagine the cauchemar if we needed to configure a filter/acl matching IPs and ports for all links everywhere! Fortunately it's just a filed that must match, nothing else. You can set it to whatever, and when the tuneel is established, you can transmit anything. So the netscreen/juniper's route-based way of configuring statically whatever you want is the best. If only they allowed several subnets to interop with the too clever vendors :) P. S. The most fantastic way of proxy-id assigning is how MS ISA does it. It allows to set IP ranges (like 192.168.1.7-99) instead of subnets in a policy/acl/however Microsoft calls it, than it automatically splits the range into subnets, fills the rest with /32s and sends all that gibberish as a proxy-id. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
