Site2Site VPN b/n Sonicwall and ASA

[engineer467]

Hello All

I could use some help here.

I have configured a site to site VPN between a sonicwall firewall and a cisco ASA(both with statuc public IPs). Now, I am facing some issues as mentioned below:

Tunnel keeps dropping (ping shows 'request timed out') when the user comes to the office every morning. Yet on sonicwall, it shows that tunnel is up, on    ASA, when I give show command for isakmp and ipsec sa, I can see the tunnel active.

   So, in order to start the ping again, I have to re enable the vpn from the sonicwall everytime this problem comes.

   I have configured 'vpn idle-timeout none' and 'vpn-session timeout none' under the group-policy assigned for that particular tunnel-group.

   The crypto isakmp and ipsec lifetime is set to 86400 on both the devices.

   'Isakmp keepalives' is enabled.

   I have tried giving a continuos ping to the peer's lan IP in the evening, but when i check in the morning, it gets 'timed out'.

Am I missing something here?

I will really appreciate any help.

Thank You

[Jon Are Endrerud]

It probably fails in rekey somwhere, I have had problems with this running ipsec between ASA and Zyxel, and som PA models. Are you sure both sides (crypto maps) matches up?

Since the tunnel is up, it can mean that phase1 is ok, but phase2 is failing.

Can you paste the debug logs from the ASA when the tunnel is hanging?

Sent from Cisco Technical Support iPhone App

[engineer467]

Thank you for the reply Jon..

Yes I double checked the configuration and crypto map does match up on both sides.

I was off work, so will paste the debug logs asap..

[TekGuruMan]

Any fix you can share?

[jesseadfi]

I am experiencing this exact same problem as well.  I have a single Sonicwall NSA 3600 and VPN tunnels to three ASA5510's.  All will be well for 18 hours, then all three tunnels will drop on the ASA side and not reconnect.  I am configured the same as the OP for lifetimes, idle timeout and session timeout.  I do not have 'Isakmp keepalives' enabled because the tunnels were dropping after two or so hours due to DPD.

On one ASA I disabled aggressive mode using 'crypto isakmp am-disable'.  For that one ASA, now when the tunnels drop, that ASA attempts to bring up the tunnel as a result of interesting traffic.  However, the tunnels still show as 'up' on the Sonicwall and they never re-establish on the ASA.

Debugs show the following in a logging loop that doesn't end until I disable then enable the VPNs on the Sonicwall, which re-establishes the VPNs:

[IKEv1]: IP = X.X.X.X, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 168
[IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
[IKEv1]: IP = X.X.X.X, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
[IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
[IKEv1]: IP = X.X.X.X, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
[IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
[IKEv1]: IP = X.X.X.X, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
[IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
[IKEv1]: IP = X.X.X.X, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
[IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
[IKEv1]: IP = X.X.X.X, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
[IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
[IKEv1]: IP = X.X.X.X, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
[IKEv1 DEBUG]: IP = X.X.X.X, IKE MM Initiator FSM error history (struct &0xac99d748)  <state>, <event>:  MM_DONE, EV_ERROR-->MM_WAIT_MSG2, EV_RETRY-->MM_WAIT_MSG2, EV_TIMEOUT-->MM_WAIT_MSG2, NullEvent-->MM_SND_MSG1, EV_SND_MSG-->MM_SND_MSG1, EV_START_TMR ERROR-->MM_WAIT_MSG2, EV_RETRY-->MM_WAIT_MSG2, EV_TIMEOUT-->MM_WAIT_MSG2, NullEvent-->MM_SND_MSG1, EV_SND_MSG-->MM_SND_MSG1, EV_START_TMR-->MM_SND_MSG1, EV_RESEND_MSG-->MM_WAIT_MSG2, EV_RETRY
[IKEv1 DEBUG]: IP = X.X.X.X, IKE SA MM:0aa36a4e terminating:  flags 0x01000022, refcnt 0, tuncnt 0
[IKEv1 DEBUG]: IP = X.X.X.X, sending delete/delete with reason message
[IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
[IKEv1]: IP = X.X.X.X, IKE Initiator: New Phase 1, Intf inside, IKE Peer X.X.X.X  local Proxy Address 10.10.10.0,
[IKEv1]: IP = X.X.X.X, IKE Initiator: New Phase 1, Intf inside, IKE Peer X.X.X.X  local Proxy Address 10.10.10.0, remote Proxy Address 192.168.0.0,  Crypto map (VPN-CRYPTO-MAP)
[IKEv1 DEBUG]: IP = X.X.X.X, constructing ISAKMP SA payload
[IKEv1 DEBUG]: IP = X.X.X.X, constructing NAT-Traversal VID ver 02 payload
[IKEv1 DEBUG]: IP = X.X.X.X, constructing NAT-Traversal VID ver 03 payload
[IKEv1 DEBUG]: IP = X.X.X.X, constructing NAT-Traversal VID ver RFC payload
[IKEv1 DEBUG]: IP = X.X.X.X, constructing Fragmentation VID + extended capabilities payload
[IKEv1]: IP = X.X.X.X, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13)
[IKEv1]: IP = X.X.X.X, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 168
[IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
[IKEv1]: IP = X.X.X.X, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
[IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0

If the original poster has found a fix for this, I will be grateful to know what it was!!!

[TekGuruMan]

Did you ever get this fixed? I have the same issue. It's incredibly annoying.

[jesseadfi]

I was not able to get it fixed.  We needed the VPN tunnels until we had a backbone link between physical sites.  Once the backbone was in place we disabled the VPN's.  Incredibly annoying is right.  I would still like to know how the OP fixed the issue.  Sonicwall support was unable to help as well.  Eventually we will need to use the VPN function again and I would like to know the solution before then.

[IndianKid]

please run this command, it keeps the tunnel alive 

isakmp keepalive threshold 10 retry 2