RV180W port forwarding culprit found!!

[Russell Racey]

Router: RV180 - RV180W, firmware: 1.0.5.4

I think this issue: about "port forwarding not working" has been around a while, afflicting some users but not others.  And it has never been resolved.  Well, I'm happy to say that I think I just put my finger on what causes it.  Not the solution mind you, but at least how to reproduce it.

The "port forwarding not working issue" just happened to me as I was reconfiguring an RV180W to add IPsec VPN tunnels.  Port forwarding for VNC (TCP 590x) was working fine up until these last changes.

I first thought it was the new firmware 1.0.5.4 which I had just downloaded.  So I bit the bullet, figuring its the old corrupt settings issue, and reset the router back to factory defaults.  Then I went step-by-step, repeating my steps, enabling port forwarding first, then keeping an eye on it as configured the rest.  Towards the end, I setup various PPTP & QuickVPN VPN clients and tested them ... ports still open.  Then I setup a IPsec client for Shrew SOFT and tested it ... ports still open.  Then I setup a Gateway-to-Gateway IPsec tunnel ... ports still open.  But, as soon as I enabled that tunnel for testing, BANG!  ... PORTS CLOSED!!

Found the culprit:  A conflict between an enabled IPsec site-to-site tunnel and port forwarding.  These two features shouldn't have anything to do with each other but there it is.  The instant as a Gateway-to-Gateway IPsec tunnel is enabled, port forwarding on the RV180W stops working.  Disable the tunnel, port forwarding resumes.

There doesn't appear anything wrong with the tunnel itself, it works fine.  I've used this configuration a bunch of times and on various types of routers. It's IKE Phase I uses 3DES & MDS, and phase II uses SHA-1 and 3DES.  PFS and DPD are enabled too.  I haven't ventured further to see if other IPsec configurations have the same effect.  But it doesn't matter, because clearly this is a bug in the RVxxx firmware itself, one that must have been around a while.  Now at least Cisco knows where to look (I hope).

CISCO, please fix?  (i.e. before you scrap the entire RV180 line in May 2015).

- Russ

[Kremena Ivanova]

Hi,

I followed your steps but port forwarding keeps working for me. Can you, please share the config file?

Regards,

Kremena

[Russell Racey]

Hi Kremena,

Very strange.  I've managed to reproduce this on two RV180W's.  Are you running the latest FW?

Anyway, I don't think it wise to post my customer's router config as it contains security information, but seeing as you are Cisco, perhaps if I email it directly to you, then you'll have what I have.  If you can send me your email address (mine should be listed under my membership), I'll reply with the attachment.

Thanks for responding so quickly.

- Russ

[cchamorr]

Hello, 

I just have a quick question that may explain the entire problem.

Can you tell us how do you create your port forwarding? To what tab do you go? 

I know it sounds like a very silly question but it has a lot of meaning. 

Most people will crate the rules under port forwarding, but that is essential wrong fro this router. Port forwarding should only be used when you are trying to translate ports, hence the last field for "Internal Port".

If you are trying to just open the ports on the router and are using the same internal and external port then you need to create those rules under "Access Rules"

When you open ports using port forward and specify the same internal port, it can create problems as it is not design to do that.

If this is your case, try recreating the port forwarding rules under Access Rules and see if it works now.

Please let us know and don't forget to mark the answer as correct if it works for you so that other users can benefit from it.

Let us know if you have any questions

[Russell Racey]

If I understand you correctly, I thought I was setting up port forwarding as it has always worked in the past on an RV180/180W:

First, I create a "Custom Service" under "Advanced Settings" - e.g. Name=VNC_5900, Type=TCP, Status=Enabled, Port Range=5900-5900.

Next, I create a "Port Forwarding" rule - e.g. Action=Always Allow, Service=VNC_5900, Status=Enabled, Source IP=Any, Destination IP=192.168.x.x, Internal Port=5900.

After saving, the RV180W automatically creates an access rule for the above - e.g. Action=Always Allow, Service=VNC_5900, Status=Enabled, Connection Type=Inbound (WAN (Internet) > LAN (Local Network)), Source IP=Any, Destination IP=blank.

After all, port forwarding has always worked fine, right up until I added GW-to-GW tunnels.  So are you saying this is what is conflicting with IPsec VPN?

When I first ran into the problem, I tried recreating port forwarding by setting up "Access Rules" first, but it had no effect.  Just response time-outs.  Not until I reset the router and manually re-entered everything did I come across the symptom of a GW-to-GW IPsec tunnel killing port forwarding the instant it was enabled.  It was like a light switch.

I am not "translating" external ports because I never had much success getting that to work in the past.  So each VNC server host on the LAN listens to a separate port.

But for the benefit of doubt, I tried disabling all my "Port Forwarding" rules leaving just "Access Rules" and "Custom Service's" -- which is the same thing as "just opening up the ports" as you prescribed.  But as I discovered a long time ago, this doesn't work, at least as as far a TightVNC is concerned.

Whenever you try to connect to the router via [WAN IP]:590x, the router immediately kicks it back triggering the VPN client to respond: "Error in TightVNC Viewer:  No connection could be made because the target machine actively refused it."  Which is utter nonsense because nothing got passed to the VNC host server on the LAN side.  You get the exact same response trying to connect to a port that has no associated LAN host.  So obviously it is the router actively rejecting those ports.  At at least there is an immediate response as opposed to no response (i.e. time-out).

So in other words, to get something as simple as TightVNC to work, you have no choice but to create a "Custom Service" then setup "Port Forwarding" rules to each VNC host LAN IP.  That has always been the workaround since the RV180W was first introduced.  VNC can't get through any other way, and apparently is still the case.  But now as I found out, a new clash occurs as soon as you enable a GW-to-GW IPsec tunnel.  Which of course even makes less sense.

I am going to test this same setup on other routers to see if I'm not imagining things.  But as far as the RV180W is concerned, I can't use it to connect to other sites via IPsec and have VNC working at the same time.  For some strange reason, the two are mutually incompatible.

- Russ

[cchamorr]

Hello Russ and thank you so much for providing such a complete answer.

First of all I want to explained that, besides working for the Small Business division of Cisco, I also happen to own this device for my own personal network, it is my main router and I have no issues with port forwarding or VPN tunnels.

I know that in general, opening ports on this router using port forwarding works, but as I tried to explain earlier, it is meant to change the internal and the external ports.

I have several ports open on my own RV180W together with site to site VPN's and I have no issue but I always open my ports suing Access Rules and that's why I would like for you to try it.

I may be mistaken and it's possible that it is not related but I would like to make completely sure this is not the issue.

Please see the attached document with the steps I would like for you to follow.

Basically I would like for you to completely delete a rule that you have created under port forwarding to open the port and re-create it using the Access Rules section.

Please let us know.

[Russell Racey]

Thank you Cchamorr.  I'll give it a whirl to see if I can get Port Forwarding to work the way you recommend.  Even if my method has always worked, probably from trial & error with early firmware, your way definitely makes more sense if not translating ports.  And like you, I have an RV180W at home too.  It has just enough tunnel capacity for my needs, and unlike the unreliable WRVS4400N it replaced, has held up remarkably well.

In the meantime, I think I found my problem.  And yes, it's my screw-up.  Because it never surfaced in other VPN router brands (e.g. Moxa, TP-Link), I got fooled into thinking it was unique to the RV180.  Until I tried the same setup on an RV042.  Since an RV042 is a mature product, it had to be something else.  And low and behold, it had to do with one particular GW-to-GW IPsec configuration; others were fine.

On routers I setup for customer systems, I also create a GW-to-GW tunnel back to my shop as a back-door.  It's sometimes easier to get gateways to connect than client-to-gateways.  Some routers, including the RV180, have an occasional habit of blocking VPN pass-through for reasons beyond me.  So a gateway-to-gateway VPN is my fast & easy Plan 'B'.

Of course when I am setup and test routers, I have their WAN's plugged into my local network (as an ISP stand-in).  By enabling a GW-to-GW tunnel that happens to share the same LAN as the WAN it is currently connected to, even if the tunnel itself is not connected, seems to confuse some routers and not others.  Obviously the RVxxx routers fall into the former category.  In this case, the conflict manifests itself into the disabling of Port Forwarding.

Knowing this, the simple workaround is to leave that particular tunnel disabled while it's plugged into my network and enable it later when I get to site.  So yes, there is a "conflict" that will catch a notice like myself off guard, but I wouldn't exactly call it a bug if the old tried & true RV042 does it too.

Anyway, I apologize for the wild goose chase.  I wish I caught my mistake sooner but needed a few more more clues to put 2 and 2 together.  But I will get back to you after trying out your simpler method of opening up ports.

Thanks,

- Russ

[cchamorr]

Hello, 

Once again, thank you very much for a very complete answer.

I'm glad you were able to find the issue and I'm happy it was not related to the actual Site to Site VPN but with a very particular configuration.

In any case, see if you want to try the new setup for the port forward (it doesn't seem like you need to), if anything so that you know of another way to do it and let us know if everything works for you.

Thank you again