I have an RV110W running firmware 184.108.40.206 that is working fine with VPN clients. However, one client cannot use VPN and I'm trying to set up some simple port-forwarding to allow RDP to a specific machine inside our network (IP address 10.143.193.2).
The tl;dr questions are:
1) Where can I find explanations of what a warning means in the logs on an RV110W?
2) Why isn't traffic from my server making it back out from our network to the originating RDP client when it seems I have configured everything to allow this to work?
I have a firewall rule that says this. (Note, I've tried restricting the services to just RDP but expanded to all traffic as part of my testing.):
And a port forwarding rule that says:
But I keep getting these errors when testing the RDP from *anywhere* at all. Searching these forums and the internet at large for the reason these are warnings and what to do has been fruitless. However, these will show up for any attempt I make to connect. Also, there were rules for each of these IP addresses that show up as warnings to allow access to the 10.x.x.2 destination. It seems that the problem is traffic isn't making it back...and I'm stumped now.
On my home network, I went so far as to disable all firewalls and still no joy...just these same warnings.
Any idea why my RDP connection is failing?
I have also been reviewing the Windows firewall rules, but they look correct. Also, I made sure logging was enabled on the server and I don't see it denying any traffic... Any help folks could provide would be appreciated. If nothing else, I'd just like to rule out the warning messages on the RV110W.
Don't use both ACL and Port forward on the Small Business routers the forward will be enough to get the traffic through the firewall.
Hope this helps.
Cisco Small Business Support Center
CCNA, CCNA - Security
But wouldn't that mean I'd have an RDP-forward open to the entire internet? Soooo, anybody could attempt to RDP into the server on my internal network?
That's a concern...I really don't want the entire internet to be able to knock on my server's door...just allow a few select IP addresses that I hardcode into the device.
Here's the closest I've come to making it work with a port-forward and access rules...it worked for at least a day but then stopped sometime over the weekend (as of this morning, it fails to work).
...and it worked. To confirm this with a test, we added a second rule for a different single IP to be sure that the rules were processing correctly. As I added and deleted, and also enabled and disabled, the rule for the single IP we used to test, the logs showed appropriate allow/deny messages. And, if the "DPT=" field in the logs is the port, we also saw this consistently report as 3389 for these attempts. Hurrah...for 24 hours or less.
This morning? We are getting the same WARNING messages that DENY traffic from IP addresses in the range that worked on Friday. And, just like before when it wasn't working...which is every day but Friday...the DPT= value is back to 3394.
This is a real "What the heck?!?!?" moment. It worked. Then it didn't.
My confidence in this device is nearing zero.
Both last week and this morning, I had a friend who is Cisco certified check what I've done and a MSCE look over the Windows server to be sure I'm not missing anything or setting things up to fail. Both are as stumped as me...especially after our testing on Friday afternoon.
I've invested a ton of time trying to make this work. At this point, even if I can't return it, I'm ready to go back to Amazon and leave a review recapping this experience and buying a competitor's product based upon the recommendation of the people who helped me this morning.
If anybody has any advice, it would be greatly appreciated. And, if this device is simply broken, it would really help if Cisco just owned up to the fact so that other people don't wind up in this same position.
I have a RV100W back in its box for similar reasons.
It was in place at a small site (10 users), basic setup with <10 port forwarding rules and <10 firewal rules. It works for anything upto a week before it starts ignoring the rules. However a reboot normally sorts it.
We waited for the new firmwire but it has not sorted it, its not heavy enough to hold a door open, so it's useless.