12-01-2009 07:37 AM
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
12-01-2009 12:18 PM
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 :)
12-01-2009 03:53 PM
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.
12-03-2009 07:06 AM
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.
12-06-2009 08:37 AM
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?
12-09-2009 01:22 PM
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 |
12-09-2009 01:39 PM
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?
12-10-2009 05:38 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide