RV130W blocks RDP via Site-To-Site VPN after several hours.

[Geoffrey]

I had two Cisco RV120Ws connecting two customer sites via VPN for five months. The connection worked well, although one of the RV120s exhibited erratic reboots for no reason, and several other anomalies. I believe that's either a RAM fault, or a corrupted configuration. I'll deal with that later.

For other reasons I just replaced the 120W at the 'hub' site with a RV130W. The Internet and VPN connections are open and up at all times. BUT...after some indeterminate time the 130W refuses (blocks, drops?) all RDP traffic coming from the satellite site. (That's the only protocol I'm interested in.)

I found other complaints about a 130W blocking traffic when related to port forwarding; a reboot made things right, but only temporarily. I have the same symptom, only it doesn't involve port forwarding. This is a straight up site-to-site VPN connection between two subnets, with satellite PCs connecting to a server via RDP. As I watched this afternoon, when the RDP sessions were failing to initiate, I still had good PING responses from all the PCs to the server in question. So the Internet link, Internet traffic, and VPN were all up and passing PINGs. After rebooting the 130W all the PCs were able to open RDP sessions, and they remained open for at least another 3.5 hours.

This is not a configuration issue, so I need to know when Cisco is going to fix this? There is only one version of firmware for the 130W, and similar complaints have been made since 2014. If there's no fix for this I'm returning the 130W.

[Joshua Beatty]

That is a very odd issue, there are a few things I would test to narrow down the possible issue. You said that pings were getting through, do you have another protocol you can test as well, SMB, HTTP, SSL. Have you tried moving the RDP port and seeing if it is the protocol or the port that is having an issue? You could also do a packet capture on the remote WAN side of the remote site to see if the traffic is tunneling or on the hub lan to see if the traffic is reaching the server but just not returning.

[Geoffrey]

Because this 130W was in use in a production environment, my test scenarios were very limited. So I cut to the easy chase. I erased the configuration, re-flashed the OS and manually reconfigured the router again. NO (as in zero) configuration parameters were changed. Since I did that there has not been an issue passing RDP through the VPN.

This is bothersome. A 'wrong' configuration might keep something from working at all, but selectively refusing traffic after a certain period of time elapses is very odd. I couldn't accidentally come up with a firewall rule to block one port. However I've had other anomalies in this line of routers that I've fixed the same way. (Like certain admin web pages failing to load properly.) Apparently there's a huge difference in the code quality from the enterprise grade Cisco gear.

Well, it's inexpensive and it's working.

[mdobiac]

Hello Geoffrey,

Thank you for the update and I am glad everything is now working.  If you have any other concerns please do not hesitate to post or contact us.

Regards,

Michael D.

If any post is helpful please rate or mark as correct.

[mjadon10291]

nice post reply my selfie Mritunjay  but you must check this out http://goo.gl/lATJOf

[keenlogic]

When you say you "re-flashed the OS", to what are you referring? I have this router in a client site and it is having issues with passing through RDP traffic after a day or two, then we have to reboot the router and works again for a short time. We would love to stop this problem from occuring.

[Geoffrey]

I downloaded the latest firmware update from the Cisco website (which was actually the same version on the router originally) and loaded that onto the router. Then I reset to the factory default configuration and reconfigured the router from scratch. I haven't seen the problem again since I did that. I can't explain it, but my original symptoms were correct and not my fantasy.

I've noticed that other things on the router (like creating client VPN connections before site-to-site connections) must be done in a certain order, or there are other issues.

Having said that, the 130W is working alright since the reload. I just bought another one to replace the 120W at the remote site.

[mdobiac]

Hello Geoffrey,

I am sorry you are experiencing this issue.  Is there a chance you can run a Wireshark on a client PC that is attempting to RDP to the server.  Additionally could you, run at the same time, Wireshark on the server while the issue is happening. 

Depending on the results gleamed from these test we may have to run a packet capture on the LAN of the router on both sides of the tunnel to see where the packet loss is occurring at.

Though in the mean time if you are willing, reflash the firmware on the RV130, get a back up of the configuration, factory default and manually configure the RV130 to see if this will eliminate or alleviate the issue.

Hope this helps,

Michael D.

If this post is helpful please rate or mark as correct.

[Geoffrey]

This is an update to my original post. I have now confirmed beyond a doubt that these Cisco 130s arbitrarily create temporary 'rules' that selectively block traffic through a site-to-site VPN. This most often happens if the routers are left up for more than a week, or if there's some other network anomaly, like a DSL line going down temporarily. We saw this originally with RDP session traffic. But now I have proof that it also selectively blocks PING packets and spooled printer traffic.

How to I know? Because first all the traffic doesn't go through, and after I reboot one router of the pair it does. This is now my first and foremost fix for network anomalies at this customer.

I've also now seen these routers fail to bring up the site-to-site VPN with bogus IPsec failures. How to I know? Once again, reboot one or both routers and the problem vanishes.

The IOS on these routers is really not up to Cisco standards. And I don't care if they're not the enterprise grade products. They should perform the basics functions as advertised.

Buying these and the RV 120s was a mistake. We should have gone directly to the ASA 5505. Or someone else's product.