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 18.104.22.168 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?
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 22.214.171.124 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?
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.
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.
Hi every one!!!When you are configuring a remote VPN connection, there
are some steps that are lost on the path. Here you can see those steps.
A) In your Cisco device: 1. Ensure you don´t have any rule denying the
traffic between the device and the remote...
** Update **These and a number of other issues have been addressed in
SRP520 MR3. Please see https://supportforums.cisco.com/docs/DOC-13853
for details on how to access this code.There have been a number of
reports of the SRP500 becoming unresponsive afte...
STANDARDSOURCECOMMENTSEthernet RJ-45 connector pin number12345678IEEE
802.3afusing data pairsRXDC+RXDC+TXDC-sparespareTXDC-sparespareIndustry
Standard for Embedded POE(used by Cisco Catalyst Switches)IEEE
802.3afusing spare pairs RXRXTXDC+DC+TXDC-DC-Indus...