02-04-2010 09:14 PM
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?
02-04-2010 10:51 PM
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.
03-09-2010 07:51 AM
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
03-09-2010 11:43 AM
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.
03-10-2010 03:47 AM
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
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