I have two sites with a RV130W router, they connect the sites with eachother through VPN.
Both routers run the newest firmware: version: 18.104.22.168. They both are directly connected to the internet (i.e. WAN-port has public IP)
The VPN has no special firewall rules or anything, it is configured to let all services through.
clients at both sides are connected to the lan side through a unmanaged switch.
Normally, when the routers start fresh, everything functions perfect, but after a while (sometimes hours, mostly 1 to 2 days) some network services/routes are spontaneously blocked.
client on site 1 cannot connect to fileserver through VPN, but can ping the fileserver. All other clients on same site are using filesharing at the same time and are ok. After router reboot, client can magically connect again.
PBX on site 2 cannot connect to PBX on site 1 anymore. pinging is ok but all other services fail to connect. after rebooting router on site 1 still same problem. after another reboot router on site 1 everything is ok.
When these problems occur, i see the following:
The client sends packets away, gets no answer and keeps retransmitting until time-out occurs.
The server on the other side doesnt receive any packets the client originally sent. I confirmed this with wireshark at both ends.
The logs on both routers do not show any ACL blocked or other signs that something is not allowed, just business as usual.
I have tried numerous things, like adding and allowing the blocked path and service in question to the firewall access rules, including logging. The log doesnt even show the access rule being triggered, it is like it doesn't even happen.
when problems occur, sometimes rebooting the router on site1 fixes it, sometimes rebooting the router on site 2 fixes it. sometimes it takes multiple reboots on both sides before it is fixed.
After this reboot, it is just a question of which service will begin to fail next. Sometimes it is RDP, sometimes Samba, sometimes VOIP.
Please help me, I am now forced to rebooting the routers almost every day which annoys the users on 2 locations as all there connections are killed and phone calls are terminated. Also we are completely unreachable for minutes at a time.
Solved! Go to Solution.
I have the same problem as well.
VERY Dissapointed and VERY frustrated with this Cisco product.
This is now causing me issues at my working environment as I'm running out of excuses.
I have 6 venues that connect with Site-to-Site IPSec VPN and all day I do all the things you've mentioned.
I'm running arround reseting the switches ON/OFF rebooting and I never understand why.
I had two friends looking at this issue both CISCO Certified as well, they both can't understand why.
Just now I upgraded to 22.214.171.124 hoping that this will solve the issue and save my job as well.
I use 3 RV130 and 3 RV130W.
KEEP AWAY especially from the RV130W WASTE OF MONEY.
To get a good WiFI signal you must be literally on top of the router, and that's IF IT WORKS.
Hello My name is Jonathan, and i am one of the Engineers here at Cisco SBSC,
I apologize for the inconvenience with the unit, i would like t o know if you have opened a case for this issues as this is the best way to solve any bugs or hardware issues.
i would like to mentioned that if you have a dynamic public ip, you will sure need a service like dyndns otherwise you may need to reestablish the tunnel whenever the ip changes. this might be the case for some of the issues if you need to troubleshoot with the unit feel free to call us and we will be glad to assist. Thanks
I am really sorry for the inconvenience you are experiencing.
Please call our line at:
So we can open up a ticket, make a remote session and determine the root cause for the issue so we can resolve it.
This type of issue is nothing new with the rv series, and frankly is not limited to just Cisco smb products. The entire segment of smb vpn routers do this from time-to-time.
Your only real solution is to figure out when the best time to reboot them is and either set them on a timer or a rebooter. There may also be a way to script a reboot.