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.
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.
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...