VPN tunnel between ASA and Juniper tears down intermittently

[CSCO11543336]

VPN tunnel between ASA 5520 ver 8.0(4) and a remote Juniper firewall keep tearing down during Phase 1 rekeying. 

After the rekeying process fails, manually pinging one of the remote hosts that are proteced behind the Juniper firewall,

initates the tunnel renegoation and rebuilds the tunnel succesfully.

When the tunnel is down,  sh crypto isakmp sa shows no active SA for the remote peer.  That indicates the PHASE 1 negotation had indeed failed.

When the tunnel is working, sh crypto isakmp sa indicates an IKE role of Responder - always.

Clearly that also means Phase 1 negotation works only one way, i.e. negotation initated by the remote Juniper unit only.

Interestingly, the Syslog server logged the following SNMP trap messages at the time rekeying Phase1.

Note, Line#2 and #7 and wrapped to the next line for easy of reading.

Line#1:   IP = Remote-Peer-IP-#, Starting phase 1 rekey

Line#2:   IP = Remote-Peer-IP-#, IKE Initiator: Rekeying Phase 1, Intf outside,

           IKE Peer Remote-Peer-IP-# local Proxy Address N/A, remote Proxy Address N/A,  Crypto map (N/A)

Line#3:   IP = Remote-Peer-IP-#, constructing ISAKMP SA payload

Line#4:   IP = Remote-Peer-IP-#, constructing NAT-Traversal VID ver 02 payload

Line#5:   IP = Remote-Peer-IP-#, constructing NAT-Traversal VID ver 03 payload

Line#6:   IP = Remote-Peer-IP-#, constructing Fragmentation VID + extended capabilities payload

Line#7:   IP = Remote-Peer-IP-#, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13)

       + VENDOR (13) + VENDOR (13) + NONE (0) total length : 148

As I understand from the above syslog trap, the Responder ( the ASA unit this time) started Phase 1 rekey (Line #1).  It prepare a message to be

sent to IKE Initiator, that it is about to start rekeying Phase 1 (Line #2). Down on the next line, it indicated that the local Proxy, remote Proxy

and Crypto map as N/A ( not avaiable).

Why would the ASA unit send N/A message as shown in Line#2, is that normal?

[Michael Muenz]

Can you please turn on debugging on the ASA and verify if the N/A messages will not be displayed when bringing up the tunnel manually?

Also check lifetime values for Phase1 and 2 on both units.

[jawad-mukhtar]

check liftime

Tunnel is consider IDLE if not data is passed from them.

*** Do Rate Helpful Posts ***

[CSCO11543336]

Debugging on isakmp and ipsec are already turned on.  That's how the syslog messages were collected in the first place,  and then posted here.

Lifetime for both phases are also matched up.

Furthermore, DPD heartbeat is manually enabled on the remote firewall.  My ASA 5520 has DPD enabled by default.

Therefore, some traffic is definately going through the tunnel, too.

But today, I'm informed that that the revision code run by the Juniper firewall has a bug, causing the null local proxy response ,etc. The bug is documented and reported as PR730675 at Juniper.  Thankfully, an upgrade fix is also made available.

An important point to recongize is that the re-keying negotation process of either phase 1 or phase 2 can be inititiated by either peer. It all depends on which peer has it's lifetime watch run out first.  For that matter, the counting down rate of the peers may not even be in sync. So matching up lifetime settings simply avoids frequent re-keying between the firewalls. It won't guarantee negotition success.

Likewise, DPD heartbeats seem to only matter when the tunnel is up.  Like in a situation where phase 1 is having trouble, enabling DPD would not help at all.