>Stig wrote >I'm not sure if this will do what you want, but you might try setting the >lifetime of the ipsec key with: >[EMAIL PROTECTED] set vpn ipsec esp-group foo lifetime >Possible completions: >[30..86400] Set lifetime in seconds
Hi Stig, Thank you for your reply. No, I wasn't talking about the IKE and IPsec SAs lifetime. I was referring to something like: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/ftsaidle.htm http://technet.microsoft.com/en-gb/library/Bb742429.aspx#EDAA To exemplify, the other end of the tunnel is represented by an ISA 2006. After about 5-6 minutes, time within the tunnel was idle(no traffic exchange between the two sides), ISA will drop the IPsec SA informing its tunnel partener about this. The IKE SA is not dropped. If the other end of the tunnel was, say another ISA, and no traffic was needed to pass through the tunnel, then no IKE QM negotiations will follow, so no IPsec SA. Once traffic destined to the remote site reaches ISA, IKE QM are started and IPsec SAs are established. I suppose the logic behind this is not to waste resources. However, Vyatta, after receiving the ISAKMP Informational packet from ISA to delete the SA, it does so and immediately starts the IKE QM negotiations to establish a new IPsec SA even when is not traffic ready to be sent through the tunnel. So we end up consuming resources instead of saving them. ISA lets me modify its idle timer through a reg hack, but it's a global modification(not per site). As said before this is not really an issue or a problem. I do not have something against maintaining the IPsec SA up throughout its lifetime. By the way, ISA does not support DPD. Thanks, Adrian _______________________________________________ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
