Since I could not find any Cisco document for guideline (Cisco only mentiond that, the shorter the ISAKMP life time, the more secure) .
I was wondering if I config the ISAKMP(phase 1) life time shorter than IPsec(phase 2) life time. What will happen when I still have traffic passing through the VPN tunnel, the ISAKMP reachs its timeout. Would phase 2 also got terminated, and re-start all the VPN negotiation from Phase 1 again?
Any help will be appreciated.
Glad to help.
If your questions have been satisfactorily answered, perhaps you may mark the post as "answered". Other forum participants may be more likely to review the post, and derive benefit from it.
If so inclined, you might also consider rating the responses from all responders.
We probably need to examine the context of your use of the term "session".
If you were to define a crypto ACL that was comprised of a single Access Control Entry (e.g.: permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255), that would typically* result in the establishment of a single ISAKMP SA, and two IPSec SAs. Lets call that a "crypto session".
As you stated, the establishment of the "crypto session" was triggered by a "session" (e.g.: TCP) between two hosts (each behind their respective tunnel endpoints). Additional sessions (e.g.: TCP) between different hosts at the two sites, do not require additional IPSec SAs. The IPSec SAs previously established, support all traffic defined by the ACE in the crypto ACL.
For each additional ACE in your crypto ACL, you would see the establishment of an additional pair of IPSec SAs (assuming traffic defined by the ACE triggers it).
If you were to define layer 4 criteria (e.g.: TCP port 80) in a crypto ACL, that would be horrendous. IPSec SAs would be negotiated for each destination/source port combination used by a host. E.g.: A single host visiting a single web site (through the crypto tunnel), would typically open multiple TCP sessions (each with a different source port), and IPSec SAs would be negotiated for each TCP session. This would rapidly deplete resources on the crypto endpoints.
We typically use P2P GRE or mGRE with IPSec to exchange dynamic routing info between sites. Because the inter-site traffic is encapsulated within GRE, only a single proxy is required.
edg01#show crypto ipsec sa
Crypto map tag: Tunnel0-head-0, local addr
protected vrf: (none)
local ident (addr/mask/prot/port): (/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (/255.255.255.255/47/0)
In this case, a single proxy is used. The IP addresses are the external physical IP addresses of the crypto tunnel endpoints. Transport mode is used (hence the 255.255.255.255 masks). The "47" refers to the GRE protocol.
* Note: Sometimes, each of the crypto peers initiates negotiations with the other, resulting in two redundant bidirectional ISAKMP SAs.