I was asked a question by a collegue today if there were any way that a keepalive
could be configured so that site to site tunnels would stay up, vs. having to have interesting traffic to allow the ISAKMP
negotiations to occur to bring up the tunnel on the ASA's.
The configuration is from a PIX running version 6.3.3 on one tunnel end to the other end which is an ASA running code 8.3.1.
Is there a feature that would leave the tunnel up?
Solved! Go to Solution.
Keepalives or DPD packets are used to sense the other side of the tunnel and make sure its up/down.
This allow the site to drop the SA if needed (and not wait until the idle timeout expires).
The IPsec tunnels have an idle timeout for phase 1 SAs and phase 2 SAs for security reasons. Normally you don't want the tunnel to be up if not used.
The tunnel is going to be established immediatly when sending interesting traffic, so the fact the the tunnel goes down is usually not a problem.
Just out of curiosity, why do you want to keep this tunnel always up, even if there's no regular interesting traffic being sent?
Thanks for the response. It has been awhile since I have configured these, but now that
you answered back with regards to the Phase 1 and Phase 2 timeouts, everything you said ma
Your question is also valid. Indeed "why do they want the tunnel up all the time"? Well this is the best answer I can throw to you.
The remote site on the other side of the clients tunnel runs a specific application called "PIE". I am not exactly sure what it is used for, I just know that there are a few individuals at the client site that depend on the PIE server at the REMOTE location.
We have had some intermittent connectivity issues to the PIE server on the other side of the tunnel.
I know from past experience that there can sometimes be a little bit of a delay, i.e., for instance when a ping is issued, the first one may time out (this because all of the ISAKMP and then I suppose the IPSEC negotiations are occuring) while the second thru fourth ping response comes thru OK (due to tunnel being established when they are fired).
it is my guess that my associate at the client site asked the question just in case there was something that he could eliminate which may have caused an issue with AT LEAST the initial connectivity to the PIE server.
I guess one option is to set both SAs lifetimes to the highest value.
configure mode commands/options:
<120-2147483647> Lifetime seconds value
Obviously having a constant PING or some sort of packet always traveling through the tunnel
will keep the tunnel up as well (some aplication sending packets once in a while).
You can try the above, however it's still not very recommended from a security perspective to
have a never-expiring tunnel.
I think turning up the SA lifetime is a fine answer. I will publish that to the client so he can configure.
I had already indicated that one way would be to write a script or in some other way automate traffic that would keep firing to keep the tunnel up.
Thanks for all of your help.
I looked at the customer PIX on the remote end and did not see what command would allow me to max out the lifetime for the SA's...
I did see the following in the available policies:
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400
isakmp policy 40 authentication pre-share
isakmp policy 40 encryption 3des
isakmp policy 40 hash md5
isakmp policy 40 group 2
isakmp policy 40 lifetime 86400
the max value I can set in the command " isakmp policy 40 lifetime" is what is already set <86400> so this is obviously not the same command as you are referencing where you refer to
"120-2147483647> Lifetime seconds value"
what is the command to change this setting?
thanks for your reply Jan.
I set up the command as specified. it worked with the one caviat that the max amount of time in seconds it would let me set was <86400>.
If configuring the sa lifetime won't help you might want to check if there is another network device k
eeping track of the state of a tcp session, perhaps a firewall. Firewalls tend t
o delete sessions after a configured idle time. If server or client still think this session is active and
sending a packet that is not a syn packet the firewall drops the packet.