Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

ASA5505 -> PIX 501 VPN seems to be "on demand"

I have setup a VPN between and ASA5505 and a PIX 501. It seems as though the VPN is "on demand" meaning if I don't use the connection to the far end private network, the connection dies and is restarted when I try to initiate connectivity back to the private network. I have two other VPNs that are connected to Cyberguards that don't exhibit this behavior. I am sure I am missing something, but how would I configure the ASA/PIX tunnel to stay up continuously.

New Member

Re: ASA5505 -> PIX 501 VPN seems to be "on demand"

I think what you are describing is the way that the Pix/ASA devices work by design. Unless there is traffic that is deemed 'interesting' by the configuration, then the SA's will eventually time out and the tunnel will drop.

New Member

Re: ASA5505 -> PIX 501 VPN seems to be "on demand"

Thanks...the only reason I really asked is that the two other tunnels I have to this ASA don't seem to re-establish like that, they seem to be always on.

Cisco Employee

Re: ASA5505 -> PIX 501 VPN seems to be "on demand"

That's the way it's always worked - both IKE and IPSec SAs have a lifetime - IKE in seconds, IPSec in seconds/kilobytes.

The PIX OS, up to version 6.3, allowed to disable IKE and configure an IPSec crypto map with manual keys - those IPSec SAs would then never timeout - check

In any case, the IPSec SA WILL BE renegotiated if a previous one has expired. Ditto for IKE - if a new IPSec SA has to be negotiated, but the IKE SA between the peers has also timed out, a new IKE SA will be negotiated, and then a new IPSec SA.

The need for the IPSec SA/IKE SA to be continuosly "up" should be rare. There is, however, one such scenario. Imagine one end having a static IP, while the other end has a dynamic one. The dynamic IP side knows how to establish a connection to the static side - while the other cannot establish a SA to the dynamic side (because of the changing IP). So, if the dynamic side would to establish an IKE SA an IPSec SA to the static side, traffic would flow OK - but if the SA times out and then the static side tries to send traffic to the dynamic side, you're out of luck.

The standard workaround in that scenario is to have traffic flowing all the time thru the tunnel - so as soon as the IPSec SA times out, a new one is immediately negotiated. Ways to do it: continuous ping from a host on the dynamic side to a host on the static side. Which means having at least one device up all the time ;)

On IOS, this could be implemented by configuring an IP SLA operation on the dynamic side towards the static side - say, a ping from the "internal" interface on remote to the "internal" interface on hub. If the src/dst pair of said SLA operation is included in the ACL defining the "interesting traffic" to be encrypted, you would achieve the expected result.

On ASA, it *might* be possible to do the same using either the SLA echo interface, or the NTP [source interface X] command. I haven't tried it. Try and let us know how it goes.