07-27-2010 07:21 AM - edited 02-21-2020 04:45 PM
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.
- Angela
Solved! Go to Solution.
07-28-2010 06:43 AM
Angela:
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
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr
protected vrf: (none)
local ident (addr/mask/prot/port): (
remote ident (addr/mask/prot/port): (
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.
Best Regards,
Mike
07-28-2010 07:27 AM
Angela:
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.
Best Regards,
Mike
07-27-2010 09:21 AM
The renegotiation will take place before the lifetime is reached. So no connections will be dropped.
The peers negotiate a new SA before crossing the lifetime threshold of the existing SA to ensure that a new SA is ready when the existing one expires. The peers negotiate a new SA when about 5 to 15 percent of the lifetime of the existing SA remains.
07-27-2010 10:35 AM
Hi Diego,
Thanks for the answer.
- Angela
04-02-2013 02:41 AM
I have tested this out in my LAB,My Findings are
1. ISAKMP SA is mainly created for IPSEC SA function , so when ISAKMP lifetime expires IPSEC SA still be continues untill it lifetime expires
2. It doesnt make sense if ISAKMP SA expires then the IPSEC SA also needs to be timeout because ISAKMP (Phase 1) is performed to make IPSEC SA (Phase 2) to function
3. When IPSEC SA lifetime expires and if the traffic initiated then the ISAKMP SA established and Followed by IPSEC SA
4. So most of the config change done on the peers need clear crypto session, if not the peers will work with the function negotiated in the last session
07-27-2010 09:24 AM
http://www.cisco.com/en/US/docs/ios/11_3/feature/guide/isakmp.html#wp6739
Check this link.
I hope it helps.
07-27-2010 09:47 PM
Angela:
Negotiating a bidirectional ISAKMP SA results in a secure channel that facilitates the negotiation of unidirectional IPSec SAs. Once the IPSec SAs have been negotiated, you could actually delete the ISAKMP SA with "clear crypto isakmp
If an ISAKMP SA did not exist for a given session when the IPSec SAs needed to be re-negotiated, a new ISAKMP SA would be established first.
Consider the following:
edg01# sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
Edit ----------------
edg01# clear crypto isakmp 2024
edg01# clear crypto isakmp 2023
edg01# clear crypto isakmp 2022
Edit ----------------
Edit ----------------
edg01# sh crypto isakmp sa
Edit ----------------
IPv4 Crypto ISAKMP SA
dst src state conn-id status
edg01# sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
Note: Takes a while for the ISAKMP SA entries to be removed from the show command output.
edg01# sh crypto session
Crypto session current status
Interface: Tunnel0
Session status: UP-NO-IKE
Peer:
IPSEC FLOW: permit 47 host
Active SAs: 2, origin: crypto map
Interface: Tunnel0
Session status: UP-NO-IKE
Peer:
IPSEC FLOW: permit 47 host
Active SAs: 2, origin: crypto map
Notice that the crypto sessions are still up (UP-NO-IKE), that there is an acknowlwdgement that there are no ISAKMP SAs (UP-NO-IKE), and that the IPSec SAs still exist (Active SAs: 2).
Prior to deletion of the ISAKMP SA for a given session, the output would have looked like this:
Interface: Tunnel0
Session status: UP-ACTIVE
Peer:
IKE SA: local
IPSEC FLOW: permit 47 host
Active SAs: 2, origin: crypto map
You could also use "show crypto ipsec sa", and observe the packet counts to convince yourself that crypto protected data continues to flow.
#pkts encaps: 10144, #pkts encrypt: 10144, #pkts digest: 10144
#pkts decaps: 10424, #pkts decrypt: 10424, #pkts verify: 10424
Sorry for the multiple edits. seem to have gotten carried away with the cut and paste.
Best Regards,
Mike
07-28-2010 04:54 AM
Hi Mike,
This is really great. It answers my question in detail. Thank you very
much.
-Angela
07-28-2010 05:07 AM
Hi Mike,
Sorry, just come up with further question regarding the same setup.
Per what I know in Cisco. ISAKMP SA,and IPsec SAs is built up per subnet by
default (per session is toooo resource consuming).
If I have simple scenario as below:
- let's say , I keep the Cisco default build up SA per subnet
- and I only set up 1 subnet behind each of the IPsec VPN end point (the
subnet on each end will be in different subnet)
- first, 1 session come up which triggered the VPN tunnel built up( 1
ISAKMP SA + 2 IPsec SAs), traffic of this single session continue flowing
through the tunnel
- When the ISAKMP reachs its timeout. we only have IPsec SAs exist, and
tunnel is still up (which is great)
- at this time, there is another session come up (different source IP and
destination IP). so, we still need to start from negotiate the phase 1 (the
ISAKMP SA), then move to build IPsec SAs. At this point of time, will the
first IPsec SAs for the first session need to torn down per Cisco's default
behavior or we will end up with 2 sets of IPsec SAs for each session ?
- Angela
07-28-2010 06:43 AM
Angela:
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
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr
protected vrf: (none)
local ident (addr/mask/prot/port): (
remote ident (addr/mask/prot/port): (
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.
Best Regards,
Mike
07-28-2010 07:08 AM
Hi Mike,
Your answer waked me up. Many many thanks to you.
-Angela
07-28-2010 07:27 AM
Angela:
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.
Best Regards,
Mike
07-28-2010 10:45 AM
Angela:
With regard to choosing appropriate lifetimes for the ISAKMP and IPSec SAs, I believe the Cisco defaults are 86400 seconds (1 day), and 3600 seconds (1 hour) respectively. The IPSec SA lifetime may also be specified in kilobytes. The IPsec SAs will