asked on

VPN between Draytek 2860 router and Cisco RV180W router keeps dropping

The VPN between a Draytek 2860 router and a Cisco RV180W and a Cisco RV120W (2 VPN's connected to the same Draytek) routers keeps dropping. It runs for a few hours then drops then starts again. There have not been any error messages since 12 PM CST on 12/6/2014. BEFORE THIS TIME The error message I was getting most of the time from the 180 is : [rv180w]Sat Dec 6 10:02:50 2014(GMT-0600) [rv180w][System][VIPSECURE] Phase 2 negotiation failed due to time up. 184e94d622736ea0:2b8d8cad8eb871c9:0000cca8.

I have also gotten this message as well (I believe this one is in part due to the Draytek negotiating in many different ways ) but I have not seen it since 5 AM CST 12/56/2014:

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's dh_group "768-bit MODP group" mismatched with Local "1024-bit MODP group".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's hashtype "SHA" mismatched with Local "MD5".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's dh_group "768-bit MODP group" mismatched with Local "1024-bit MODP group".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's encryption type "3DES-CBC" mismatched with Local "DES-CBC".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's dh_group "768-bit MODP group" mismatched with Local "1024-bit MODP group".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's encryption type "3DES-CBC" mismatched with Local "DES-CBC".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's dh_group "1536-bit MODP group" mismatched with Local "1024-bit MODP group".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's encryption type "3DES-CBC" mismatched with Local "DES-CBC".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's hashtype "SHA" mismatched with Local "MD5".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's dh_group "1536-bit MODP group" mismatched with Local "1024-bit MODP group".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's encryption type "3DES-CBC" mismatched with Local "DES-CBC".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's encryption type "AES-CBC" mismatched with Local "DES-CBC".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's encryption type "AES-CBC" mismatched with Local "DES-CBC".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's hashtype "SHA" mismatched with Local "MD5".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's encryption type "AES-CBC" mismatched with Local "DES-CBC".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's dh_group "1536-bit MODP group" mismatched with Local "1024-bit MODP group".

[rv180w]Sat Dec 6 07:01:36 2014(GMT-0600) [rv180w][System][VIPSECURE] Phase 2 negotiation failed due to time up. 9e2eba21d7fb1bf8:ae5cbe65024c211a:0000d4fa

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's hashtype "SHA" mismatched with Local "MD5".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's dh_group "1536-bit MODP group" mismatched with Local "1024-bit MODP group".

[rv180w]Sat Dec 6 05:04:42 2014(GMT-0600) [rv180w][System][VIPSECURE] Rejected phase 1 proposal as Peer's encryption type "AES-CBC" mismatched with Local "DES-CBC".

The remote user's telephones at the remote side (Cisco RV180W) rely upon the VPN working so it is critical I get this fixed.

Please advise ASAP.
Jeff Hind
Telecom Cost Solutions LLC
Sioux Falls, SD
605.366.9389

tolinrome

Do you have access to to the Draytek? It seems as if the encryption and authentication arent matching, login to see and make the match, no?

Qlemo

It might be important which device initiates the tunnel negotiation. The RV180 log tells that the Draytek is configured to supply several proposals. You should make sure only the one valid proposal is set up.

The first message sounds like an timeout of the phase 2 SA because of different lifetime settings on all devices; probably you work with the default values. This leads to premature invalidation on the Draytek.

tcsjeff

ASKER

@ Tolinrome. I do have access to the Draytek which is at the main location, and I will verify the encryption and authentication do match, but my understanding is that they do match as the VPN has been working but drops and re-starts intermittently.

tcsjeff

ASKER

@ Olemo The Draytek is set up to provide different proposals ( it was set up that way the the distributor tech support). Are you suggesting I change it to only one that matches the Cisco? I have not had the error message about phase 1 since I got the VPN working last Saturday 12/6/2014 @ 12:00 PM CST. For that matter I have not gotten the other error message either.

The timeouts for phase 1 are set at 28800 for both routers and for phase 2 are set at 3600 for both routers.

The tech from Draytek asked me this question : "Is there any VPN connection on Cisco side duplicated the subnet with this VPN?" I do not know what he means by this. I did ask him and I am waiting for his reply.

If anyone has a possible answer please feel free to jump in.

Thanks

Jeff

tcsjeff

ASKER

I did verify the encryption and authentication and they do match on both routers.

Qlemo

If the IPsec parameters are the same, I see no reason for failure or interruption.

The tech asks whether there are other VPN configured for the same subnets as the Draytek site.

tcsjeff

ASKER

@ Olemo
That is my predicament. Parameters are the same yet it seems to drop. The VPN has been up now for over 3 hours. The fact that is running tells me the parameters are correct. If I was to see a pattern in the dropping it is when there is no activity on the VPN. No data or phone calls being transmitted or received. The Draytek technician suggested I enable "always on". When I did this, the call direction automatically changed from both to dial out. The VPN dropped within 20 minutes or so. As soon as I changed from always on to an idle time out of 0 seconds and changed the call direction back to both, the VPN came back up.

I checked and the subnet mask for the WAN and LAN at the Draytek location is the same as the subnet mask for the Cisco location

Thank you for your help.

Jeff

Qlemo

... and at Cisco no other VPN is defined?

tcsjeff

ASKER

Qlemo
I apologize I spelled your name wrong the last couple of times. I see I used a O instead of a Q.
The Cisco end only has the one VPN to the Draytek. There are no other VPN's in the Cisco.

The Draytek (located at the home office) has two different VPN's in it. One to the Cisco RV180W (the one we are discussing) and one to a Cisco RV120W.
Both Cisco ends have the same internet provider (separate accounts and billing) but are on opposite sides of the city. Both VPN's drop intermittently but the RV180W drops more than the RV120W.

Thank you again for your help.

Jeff

Qlemo

The idle timer is another potential reason for closing the VPN, and cause renegotiation. DPD might prevent closing the tunnel, so that is worth a try.

tcsjeff

ASKER

DPD? I do not know what you mean by that. I am inexperienced in a lot of these terms. Can you educate me (it can be a hard task. LOL ).

Jeff

Qlemo

"Dead Peer Detection" - kind of keepalive ping between VPN devices.

tcsjeff

ASKER

This is enabled on the Cisco. Here is what it is set at: Dead Peer Detection:      Enabled
Detection Period:      10 (Range: 10 - 999)
Reconnect after Failure Count: 3 (Range: 3 - 99)

In reading other comments and there is an option for this on the Draytek Vigor, pinging an ip address may help keep the VPN alive. Would I ping the static IP of the remote end or the local IP of the actual router on site? And does the cisco router need to respond to ping on the WAN?

Qlemo

You ping something on remote LAN (private IP).

tcsjeff

ASKER

Does the router have to be set to respond to ping on wan or just leave that off and maybe just ping the pbx or one of the computers on the lan?

ASKER CERTIFIED SOLUTION

Qlemo

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

tcsjeff

ASKER

Ended up replacing Cisco 180 with a different router. Seemed to help but not 100% full proof.
VPN still drops intermittently between the Draytek and the other routers. But does seem to come back up on it's own.