RV042 VPN dying

Unanswered Question
Dec 1st, 2009
User Badges:

I have an RV042 that has a VPN gateway connection that periodically just dies. The connection will be fine for a day and then simply die. I was previously using a wrv200 gateway to gateway and had no issues at all. The issues only came about when I removed the wrv200 and added the rv042 for load balancing reasons. The connection is static to static with the following parameters.


vpn connection is mux'd T1

mtu1500


ike with preshared

ph1

group5

aes-128

md5

sa life 86400


no pfs

ph2

aes-128

md5

sa life 3600


aggressive

keep alive

DPD


There is a connection event logged every hour (3600 secs), but the connection will just die all of a sudden, for no reason, and no event is logged. It still shows connected in the rv042. I can click disconnect and then it comes back up with no problem.



Here is the connection log.

   [Tunnel Negotiation Info] >>> Initiator Send Aggressive Mode 1st packet    initiating Aggressive Mode #1, connection "ips1"    STATE_AGGR_I1: initiate    Ignoring Vendor ID payload Type = [XAUTH]    Received Vendor ID payload Type = [Dead Peer Detection]    Ignoring Vendor ID payload Type = [Cisco-Unity]    Ignoring Vendor ID payload [xxxxxxxxxx...]    [Tunnel Negotiation Info] <<< Initiator Received Aggressive Mode 2nd packet    Aggressive mode peer ID is ID_IPV4_ADDR: 'xxx.xxx.xxx.xxx   [Tunnel Negotiation Info] >>> Initiator send Aggressive Mode 3rd packet    [Tunnel Negotiation Info] Aggressive Mode Phase 1 SA Established    [Tunnel Negotiation Info] Initiator Cookies = xxxx xxxx xxxx xxxx   [Tunnel Negotiation Info] Responder Cookies = xxxx xxxx xxxx xxxx   initiating Quick Mode PSK+TUNNEL+AGGRESSIVE    [Tunnel Negotiation Info] >>> Initiator send Quick Mode 1st packet    Received informational payload, type IPSEC_RESPONDER_LIFETIME    [Tunnel Negotiation Info] <<< Initiator Received Quick Mode 2nd packet    [Tunnel Negotiation Info] Inbound SPI value = xxxxxxxx   [Tunnel Negotiation Info] Outbound SPI value = xxxxxxxx   [Tunnel Negotiation Info] >>> Initiator Send Quick Mode 3rd packet


   [Tunnel Negotiation Info] Quick Mode Phase 2 SA Established, IPSec Tunnel Connected

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Alejandro Gallego Tue, 12/01/2009 - 12:18
User Badges:
  • Cisco Employee,
Ignoring Vendor ID payload Type = [XAUTH]   
Received Vendor ID payload Type = [Dead Peer Detection]   
Ignoring Vendor ID payload Type = [Cisco-Unity]  


One thing I would look into is removing any "ID" information that may be being sent from the Cisco. Also, you stated that you were connecting static to static; so I will assume that you are connecting via IP address not FQDN (as it appears in the log). Since we are not resolving FQDN remove "Aggressive" mode from the tunnel. If the problem persists change the DH group from 5 to 2.


One question:

In the following edited log entry, is the value a single hex srting or multiple line?

Ignoring Vendor ID payload [xxxxxxxxxx...]   

keep us posted :)

stevejfrank1 Tue, 12/01/2009 - 15:53
User Badges:

Unchecked Aggressive mode 12/1 3:48PM.


To answer your question it is a single hex string 16 characters long with '...' at the end


Should it be a single string or multiple strings?


Also, I don't have access to the remote Cisco device so I can't change DH group. Current settings worked just fine with the WRV200. WRV200 didn't have Aggressive mode as an option so my fingers are crossed that this change will solve the issue.


I'll report back if this fixes it.

Alejandro Gallego Thu, 12/03/2009 - 07:06
User Badges:
  • Cisco Employee,

Sorry for the late reply,

IDs can be used to further identify the tunnel end points. Most "Enterprise" level routers have this option but it is not required. Depending on how the ID is configured it can cause the tunnel to either not connect or just not allow traffic to pass. I have seen this field be a multi-line hex output in the log, which typically suggests a problem with encryption. I do not think this is the case here though.

Hope all is working at this point.

stevejfrank1 Sun, 12/06/2009 - 08:37
User Badges:

The problem still persists. It lasted three days and then the vpn connection just stopped working. It shows connected as the status, but packets just die. I have to click disconnect and then it starts working again. I have verified all settings to the remote router. Any other suggestions?

stevejfrank1 Wed, 12/09/2009 - 13:22
User Badges:

Well it disconnected again. This time it was approximately 36 hours later. Here are the log entries leading up to my admin login to disconnect the vpn connection. It seems after the 9:15:54 connection the tunnel just didn't work.


Do you have any other suggestions?


Dec 9 07:16:50 2009    VPN Log   [Tunnel Negotiation Info] <<< Responder Received Quick Mode 1st packet
Dec 9 07:16:50 2009   Connection Accepted   UDP x.x.x.x:500->6x.x.x.x:500 on ixp2
Dec 9 07:16:50 2009    VPN Log   [Tunnel Negotiation Info] Inbound SPI value = xxxxxxxx
Dec 9 07:16:50 2009    VPN Log   [Tunnel Negotiation Info] Outbound SPI value = xxxxxxxx
Dec 9 07:16:50 2009    VPN Log   [Tunnel Negotiation Info] >>> Responder send Quick Mode 2nd packet
Dec 9 07:16:50 2009    VPN Log   [Tunnel Negotiation Info] <<< Responder Received Quick Mode 3rd packet
Dec 9 07:16:50 2009    VPN Log   [Tunnel Negotiation Info] Quick Mode Phase 2 SA Established, IPSec Tunnel Connected
Dec 9 07:16:50 2009    VPN Log   Dead Peer Detection Start, DPD delay timer=30 sec timeout=10 sec
Dec 9 08:15:48 2009    VPN Log   [Tunnel Negotiation Info] <<< Responder Received Quick Mode 1st packet
Dec 9 08:15:48 2009   Connection Accepted   UDP x.x.x.x:500->x.x.x.x:500 on ixp2
Dec 9 08:15:48 2009    VPN Log   [Tunnel Negotiation Info] Inbound SPI value = xxxxxxxx
Dec 9 08:15:48 2009    VPN Log   [Tunnel Negotiation Info] Outbound SPI value = xxxxxxxx
Dec 9 08:15:48 2009    VPN Log   [Tunnel Negotiation Info] >>> Responder send Quick Mode 2nd packet
Dec 9 08:15:48 2009    VPN Log   [Tunnel Negotiation Info] <<< Responder Received Quick Mode 3rd packet
Dec 9 08:15:48 2009    VPN Log   [Tunnel Negotiation Info] Quick Mode Phase 2 SA Established, IPSec Tunnel Connected
Dec 9 08:15:48 2009    VPN Log   Dead Peer Detection Start, DPD delay timer=30 sec timeout=10 sec
Dec 9 09:14:54 2009    VPN Log   [Tunnel Negotiation Info] <<< Responder Received Quick Mode 1st packet
Dec 9 09:14:54 2009   Connection Accepted   UDP x.x.x.x:500->x.x.x.x:500 on ixp2
Dec 9 09:14:54 2009    VPN Log   [Tunnel Negotiation Info] Inbound SPI value = xxxxxxxx
Dec 9 09:14:54 2009    VPN Log   [Tunnel Negotiation Info] Outbound SPI value = xxxxxxxx
Dec 9 09:14:54 2009    VPN Log   [Tunnel Negotiation Info] >>> Responder send Quick Mode 2nd packet
Dec 9 09:14:54 2009    VPN Log   [Tunnel Negotiation Info] <<< Responder Received Quick Mode 3rd packet
Dec 9 09:14:54 2009    VPN Log   [Tunnel Negotiation Info] Quick Mode Phase 2 SA Established, IPSec Tunnel Connected
Dec 9 09:14:54 2009    VPN Log   Dead Peer Detection Start, DPD delay timer=30 sec timeout=10 sec
Dec 9 09:19:04 2009    Authentication Success   HTTP Basic authentication succeeded for user: admin


stevejfrank1 Wed, 12/09/2009 - 13:39
User Badges:

The one setting that I noticed that is different is the DPD timeout setting. The log shows that it is 10 seconds. In the last router I had it set to 120 seconds.


Where is this set in the RV042? Could this be causing the issue?

Alejandro Gallego Thu, 12/10/2009 - 05:38
User Badges:
  • Cisco Employee,

Dead peer detection should be at the bottom of the tunnel set up page. From the log you posted it does not seem that DPD is the problem, but definately worth a try. All we see in that log is the tunnel continually renegotiating, is it possible to see the log from the other side? One thing to try is deleting the tunnel and recreating it, but using a different tunnel name on the RV.


You may want to call Small Business Center and open a support ticket.


866.606.1866

Actions

This Discussion