RVS4000 Site to Site VPN Disconnection Issues

thebeck76 · ‎02-04-2010

Hello,

I have five (5) RVS4000's setup at five (5) different locations with site-to-site VPN configured between them all. I am using "IP by DNS Resolved" for the remote group with dyndns.org as my dynamic DNS service. All routers are running the 1.3.0.5 firmware.

My issue is that VPN tunnels seem to go down every so often. Sometimes I can go weeks without it going down. Sometimes it is within days of a reboot.

Sometimes simply hitting the respective "Connect" button on the VPN summary (or IPSec VPN Details) page for the local router re-establishes the connection and sometimes it does not. Sometimes I have to access the remote admin UI (https://xxxxx:8080/) to hit the respective "Connect" button to re-establish the connection, which sometimes works and sometimes does not work. And other times I have to reboot at least one of the routers to get the connection to re-establish.

This type of behavior does not seem correct. Is anyone else seeing this behavior? Are there any strategies I can use to diagnose the issue?

Tiya Rabb · ‎02-04-2010

I agree thebeck76, this behavior is out of the norm. I have one suggestion that may assist you in your diagnosis:

I am using "IP by DNS Resolved" for the remote group with dyndns.org as my dynamic DNS service.

Have you tried configuring the tunnel using "IP Only" & "IP by DNS Resolve" for remote gateway IP addresses? If not, give this a try.

thebeck76 · ‎03-09-2010

Hi Tiya,

Thank you for your reply. Below is how all of my routers are setup (with different local IP address, of course). What you suggest is exactly what I have been using, I believe.

I have now upgraded them all to the 1.3.1.0 firmware and the problem still persists. Essentially, the tunnel gets created successfully and I can access the remote networks just fine. Then, after a period of time (which I cannot figure out), the connectivity ceases.

Pinging the remote gateway does not re-establish the VPN connection. Logging into the admin interface and manually trying to "connect" also does not re-establish the VPN connection. I have to reboot at least one of the routers to get the VPN connection to establish. In some cases (not all the time, though), one of the routers will actually show as connected while the other shows disconnected (even if I hit the connect button on the "disconnected" router, it still shows disconnected).

Do you by chance have any other thoughts? Is there a defect in the Firmware that manifests itself only after a certain amount of time? Should I be using a different configuration for Phase 1 and Phase 2?

You advice is greatly appreciated.

Best.

Local Group Setup

Local Gateway Security Type: IP Only

IP Address: xx.xx.xx.xx

Local Security Group Type: Subnet

IP Address: yy.yy.yy.yy

Subnet Mask: 255.255.255.0

Remote Group Setup

Remote Security Gateway Type: IP Only

IP by DNS Resolved: dddd.dddddd.com

Remote Security Group Type: Subnet

IP Address: zz.zz.zz.zz

Subnet Mask: 255.255.255.0

IPSec Setup

Keying Mode: IKE with Preshared Key

Phase 1

Encryption: 3DES

Authentication: MD5

Group: 1536-bit

Key Lifetime: 28800 sec

Phase 2

Encryption: 3DES

Authentication: SHA1

Perfect Forward Secrecy: Enable

Passphrase Key: ppppppppp

Group: 1536-bit

Key Lifetime: 3600 sec

Advanced

Aggressive Mode: Off

NetBios Broadcast: On

thebeck76 · ‎03-09-2010

I just had a thought... Is it possible that the router is "caching" the dynamically resolved IP address?

If the WAN side of the connection gets a new public IP address (on Router A), when, say the WAN side renews its DHCP lease, the IPSec Site-to-Site VPN connection will obviously break. If Router B is using the "cached" IP address instead of re-looking up the IP address, could that be the cause of my issue?

Router A may say that it is "still" connected to Router B, but since Router B is using the old IP Address for Router A, it will say it is not connected to Router A.

wichilds · ‎03-10-2010

Beck76,

Your assumption sounds accurate, and very reasonable. On some models of our routers, we have the ability to do dead peer detection (DPD). This function tries to ping through the tunnel and when it gets an unsuccessful set of pings and assumes the tunnel is down, then it tries to reconnect the tunnel. Therefore it would/should run a new dns query to the dns name and THEN reconnect the tunnel with no administrator/end user interaction.

It looks like this feature is missing from the RVS4000, which regretably for you is unfortunate. I would also wager that the reason this feature is missing would point to a hardware limitation. I can't imagine the designers leaving this important feature out if the hardware supported it.

My recommendation:

Get static IPs at each site.

Bill