In article , AM wrote: :isakmp policy 10 authentication pre-share :isakmp policy 10 encryption 3des :isakmp policy 10 hash md5 :isakmp policy 10 group 1 :isakmp policy 10 lifetime 86400
:isakmp policy 20 authentication pre-share :isakmp policy 20 encryption 3des :isakmp policy 20 hash md5 :isakmp policy 20 group 2 :isakmp policy 20 lifetime 86400
For 3DES, group 2 is usually preferred, so you would normally put the version with group 2 as a lower number (higher priority) than the group 1.
:isakmp policy 30 authentication pre-share :isakmp policy 30 encryption 3des :isakmp policy 30 hash md5 :isakmp policy 30 group 2 :isakmp policy 30 lifetime 86000
That duplicates policy 20 except for the lifetime, but lifetimes are not used to choose proposals: instead, the proposal is chosen, and the shorter of the two lifetimes (from the two ends) is used. You might as well remove policy 30 and the policy 40 that follows, as they will never be selected.
:isakmp policy 50 authentication pre-share :isakmp policy 50 encryption 3des :isakmp policy 50 hash md5 :isakmp policy 50 group 1 :isakmp policy 50 lifetime 28800
Similar lifetime consideration (except vs policy 10.)
:is a good list or could give me problems?
I would suggest that you should have a 3DES SHA in there. SHA is more secure than MD5, so MD5 is often not used except with plain DES (PIX 6.3 does not support DES + SHA).
I know you are running PIX 6.3, so I would suggest that your first policy should be AES-128 group 5. That's faster than 3DES and is at least as secure.
:When managing VPNs to different vendors it seems to me that the order of that list is important. Is this true or not?
Yes. Each end will send a list of proposals to the other end, with the lowest numbered policy first in the list. The receiving end will choose the first one on the list that it also supports (no matter what priority is assigned to it on the receiving end.) Thus, the policy is chosen by the receiving endpoint of the tunnel, and the policies of the two tunnels is chosen independantly -- it is considered completely valid to have strong encryption in one direction and no encryption in the other direction.
:Perhaps lifetime should be specified in ascending order when the same parameters (hash and encr.)are specified?
It is not used as a selector.