Need Default VPN Tunnel Lifetimes for Cisco ASA 5505
What are the default VPN tunnel lifetimes for both Phase 1 and Phase 2 in a Cisco ASA 5505?
We have a Sonicwall NSA 4500 setup with a site-to-site VPN tunnel to a Cisco ASA 5505. We are experiencing issues where the tunnel stops responding after exactly 32 minutes. It goes down for a few minutes and then comes back up for exactly 30-32 minutes again. I cannot tell precisely how many minutes but by the time we are alerted it shows to be 32 minutes. The 32 minutes is always a constant regardless of lifetimes set in the Sonicwall though the time the tunnel stays down varies according to the lifetimes I set in our Sonicwall. I have read online that the Cisco is very picky about lifetimes matching on both sides. I am unable to contact the techs at the company on the remote side. Can someone please let me know the default lifetimes, whether it is 86400, 28800, 3600 or some other value, and give them for both Phase 1 and Phase 2. Thanks!
We have a Sonicwall NSA 4500 setup with a site-to-site VPN tunnel to a Cisco ASA 5505. We are experiencing issues where the tunnel stops responding after exactly 32 minutes. It goes down for a few minutes and then comes back up for exactly 30-32 minutes again. I cannot tell precisely how many minutes but by the time we are alerted it shows to be 32 minutes. The 32 minutes is always a constant regardless of lifetimes set in the Sonicwall though the time the tunnel stays down varies according to the lifetimes I set in our Sonicwall. I have read online that the Cisco is very picky about lifetimes matching on both sides. I am unable to contact the techs at the company on the remote side. Can someone please let me know the default lifetimes, whether it is 86400, 28800, 3600 or some other value, and give them for both Phase 1 and Phase 2. Thanks!
ASKER
MikeKane,
Is it 86400 for both Phase 1 and Phase 2?
Is it 86400 for both Phase 1 and Phase 2?
The simple answer provided you do not have access to look at the settings on the ASAs, is based on your experience. What are the settings on your side for sa lifetime and key lifetime?
It might be also set based on the amount of data transferred. The easiest is to ask the ASA admin to see what their settings are and adjust yours accordingly.
show crypto ipsec sa
show crypto isakmp sa
There should is an entry dealing with the lifetime setting time based or transmitted data size/seconds remaining.
as others pointed out, the lifetime can be what the configuration sets.
There are draw backs to too short periods as well as too long periods.
It might be also set based on the amount of data transferred. The easiest is to ask the ASA admin to see what their settings are and adjust yours accordingly.
show crypto ipsec sa
show crypto isakmp sa
There should is an entry dealing with the lifetime setting time based or transmitted data size/seconds remaining.
as others pointed out, the lifetime can be what the configuration sets.
There are draw backs to too short periods as well as too long periods.
ASKER
I am unable to contact the client company IT department possibly due to the holidays. The default lifetimes in the Sonicwall are 28800 for both Phase 1 and Phase 2. I am simply trying to find out what the values are likely to be in the remote Cisco ASA 5505, assuming the tech accepted default values, so I can match them. I have a partial answer but I am still needing to know if acceptance of default values results in a lifetime of 86400 for both Phase 1 and Phase 2 in the Cisco.
Check the log of your sonic wall when the 30 minute event occurs to see what is being reconfigured, i.e. sa lifetime or key lifetime. Adjust one to 1800 and see whether it improves the situation. If it does not try the other.
If you can debug the VPN establishment session, those parameters are sent through the negotiation.
If you can debug the VPN establishment session, those parameters are sent through the negotiation.
ASKER
Wireshark shows the tunnel is up with SPI in both directions then "Informational" packets come from the Cisco followed by "Quick Mode" showing apparently that the Cisco intiated renegotiation. After this SPI is active only in the direction from our Sonicwall to the Cisco, nothing in return. Wireshark shows this occurs 30 minutes and 15 seconds after the tunnel comes up successfully. Adjusting the lifetimes in the Sonicwall only affect how long the tunnel stays down after these renegotiations fail. The tunnel always goes down after 30 minutes.
The default for phase 1 "rekeying" is 86400, which looks like this on a ASA:
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
For phase 2 here is excerpt from the excellent "The Complete Cisco VPN Configuration Guide":
The "set security-association lifetime" parameter changes the default lifetime of the data connections. In seconds, the default is 28,800 seconds and the amount of traffic transmitted is 4,608,000KB. This value has to do with the expiration of the key for the SA. Once reached the devices "rekey".
So both values are "rekeying" times and not drop the VPN connection timers.
Did you see this Cisco Tech-Note about ASA and SonicWall setup? I mention it because they modified the PIX to be the 28800 value.
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a008052c9d4.shtml
I would try modifying your SonicWall to be 86400 for phase 1 and see what happens. I am guessing your are having a mismatch and the tunnel is coming down.
ASKER
I neglected to say that the tunnel will stay up even with lifetimes on our side set to 900 (15 minutes). It still stays up for 30 minutes and then renegotiation by the Cisco makes it fail. when the lifetime on our side was 28800 it would stay down 5+ hours. With it set to
ASKER
norgetek,
I currently have our side setup with phase 1 86400 and phase 2 86400. The tunnel still (apparently) gets a renegotiation request from the Cisco after 30 minutes and the tunnel goes down and stays down until the Sonicwall renegotiates the tunnel. I say it goes down, it looks like it comes up in only one direction. When this failure occurs the Sonicwall still shows the tunnel to be up event though it cannot pass traffic.
I have disabled keepalives on our side and am now relying only on ping to keep the tunnel up. I know they do not have keepalives enabled on thier side. I will see if that makes any difference. If not I will try phase 1 86400 and phase 2 28800 unless youm or someone, can verify the default value for phase 2 in a Cisco ASA 5505 is 86400 like in phase 1.
I currently have our side setup with phase 1 86400 and phase 2 86400. The tunnel still (apparently) gets a renegotiation request from the Cisco after 30 minutes and the tunnel goes down and stays down until the Sonicwall renegotiates the tunnel. I say it goes down, it looks like it comes up in only one direction. When this failure occurs the Sonicwall still shows the tunnel to be up event though it cannot pass traffic.
I have disabled keepalives on our side and am now relying only on ping to keep the tunnel up. I know they do not have keepalives enabled on thier side. I will see if that makes any difference. If not I will try phase 1 86400 and phase 2 28800 unless youm or someone, can verify the default value for phase 2 in a Cisco ASA 5505 is 86400 like in phase 1.
the default timeout for the sonicwall is 28800. within the settings of the sonicwall SA, go to the last tab and there is a check box called Keep Alive. if the VPN is timing out, then this check box might keep it from disconnecting.
the timeout has to be the same for both phase 1 and phase 2. if they are different, then i've seen the vpn not connect. it's possible if they are different, that it could exhibit the behavior you're experiencing. so, i'd recommend setting the sonicwall to the default timeout of the Cisco. i believe by default both phases are the same on the cisco...not being a cisco tech, i could be wrong.
the timeout has to be the same for both phase 1 and phase 2. if they are different, then i've seen the vpn not connect. it's possible if they are different, that it could exhibit the behavior you're experiencing. so, i'd recommend setting the sonicwall to the default timeout of the Cisco. i believe by default both phases are the same on the cisco...not being a cisco tech, i could be wrong.
ASKER
I hope someone can verify the default keepalive value for Phase 2 in the Cisco. Interestingly I have just discovered that if I turn off keepalive in the Sonicwall the tunnel stays up beyond 30 minutes! I read online that the Cisco could have problems with third-party keepalives and mismatched keepalive settings. Stopping our keepalive, and relying only on ping to keep the tunnel up, appears to have made a difference.
Still waiting for a definitive answer on what phase 2 keepalive defaults to in a Cisco ASA 5505. Thanks for all the comments and assistance so far!
Still waiting for a definitive answer on what phase 2 keepalive defaults to in a Cisco ASA 5505. Thanks for all the comments and assistance so far!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Cisco ASA do have issues with 3rd party devices when attempting to do keep alives. Of course if the other person has his on there isn't much you can do about that.
ASKER
norgqtek,
That is exactly what I was looking for! One of the first things I had done was disable the keepalives on our side and the tunnel kept going down. After reenabling it I changed the keepalives to many different values and the tunnel kept goinf down. It appears that the tunnel is now staying up with both thigns changed. I have it set to 86400 for phase 1 and phase 2 with keepalives also disabled. I will change the phase 2 to 28800 and when I can reach the client IT admin ask them to enable keepalives on their end. Thank you for the answer I was needing and thanks to everyone else who responded.
That is exactly what I was looking for! One of the first things I had done was disable the keepalives on our side and the tunnel kept going down. After reenabling it I changed the keepalives to many different values and the tunnel kept goinf down. It appears that the tunnel is now staying up with both thigns changed. I have it set to 86400 for phase 1 and phase 2 with keepalives also disabled. I will change the phase 2 to 28800 and when I can reach the client IT admin ask them to enable keepalives on their end. Thank you for the answer I was needing and thanks to everyone else who responded.
I'm not sure there is a 'default' since the IKE proposals have to be entered by the firewall admin. But When I go through the ASDM wizard to create a new IKE proposal, the Lifetime field is pre-filled with 86400... if that answers your question.