RV180 NAT loopback bug?

[semenko86]

I'm trying to set up an RV180 router as a replacement for some non-Cisco gear, but I can't seem to get NAT loopback to work.

That is:

- The client has an external IP, say X.X.X.X, and uses NAT for bunch of 192.168.1.0/24 internal addresses

- An internal server (say 192.168.1.123) hosts an important business app on :443 SSL

- The router tunnels any external connections to X.X.X.X:443 to the internal server 192.168.1.123:443

This works perfectly for external users (e.g. visiting X.X.X.X:443 works fine) but internally accessing the WAN IP (X.X.X.X:443) does not work, and instead loads the router login page.

This is particularly problematic, since our users access this via a CNAME that points to the WAN IP.

- Is this a known bug & are there any workarounds on the router?

- Is there an easier or more private way to report bugs than forum posts?

- Is there any beta firmware that might fix this issue?

[rocater]

Hello semenko86,

This is not an issue I have heard before for this device. If you are looking to report this issue, it is always best to call in to our support center so we can open a case and track any problems. In this way, if we determine that the problem is a bug, we can then send the case on up. As with all firmware, we continue to work to resolve any issues, but we do not get information on if there is beta firmware available. Please see below for a number to call us here at the SBSC.

http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html

[john.checco]

Have you found a solution to this?  I just upgraded from my old Linksys RV016 to this RV180, and this is definitely an issue...

[linksysinfo]

Could you not add a workaround in the HOSTS file and use the internal address? or have the CNAME point to the internal address?

Regards Simon
http://www.linksysinfo.org

[john.checco]

Update HOSTS on every server and workstation? i don;t think that is an effective workaround. 

I've since returned the RV180 and will stick with my trusty old LinkSys RV016 (which effortlessly supports NAT hairpinning)

[semenko86]

Nope -- there are no non-hackish workarounds yet.

This is a pretty big issue, pondering returning the RV180W over it.

So far, there are lots of little & annoying bugs. Traceroute, for example, returns a spoofed packet for the first hop that breaks some apps.

(Try to traceroute to any endpoint outside your LAN and note the first packet)

[rmanthey]

Hello everyone,

What is the current firmware those that are having the issue on?

The current release firmware is not yet available on the Cisco site 1.0.1.9

Please call in to the support center at 1-866-606-1866 if you don't have the current release.

Cisco Small Business Support Center

Randy Manthey

CCNA, CCNA - Security

[semenko86]

I'm on the stock firmware (1.0.0.30) since I haven't heard of any others.

 Please call in to the support center at 1-866-606-1866 if you don't have the current release.

This is pretty painful. I made the call 30 minute ago, now waiting for a call back after they check the database to see if this is a known issue and whether they can escalate this ticket to get the firmware ...

[h3lbr0_123]

I am having the same problem!

Did you ever get an answer on whether this is a known issue or if they are going to escalate this ticket?

Does anyone else know how to fix this?

Thanks,

Nick

[TekMason0]

semenko86,

Thanks for the mention of the first hop spoofing issue.  The latest firmware (1.0.1.9) doesn't fix it.

First Hop Spoofing with Traceroute on RV180 is a thread I've started on this issues.

TekMason

[onlyalex1984]

Try

Firewall --> Access rules. Remove the rule that points to port 443.

Firewall --> Advanced settings --> Custom Services. Remove any rule that points to port 443.

After you have removed the above rules try to create them again and redo your test.

If that does not work, try another port than port 443.

I know that with the new 1.0.4.17 firmware i had to do this to make hairpining work again and it applied for my custom ports " not tested on 443 do" Now hairpining works but not using ssl vpn for some reason. For some reason this feature works on some fw, but is later broken in another fw version and around it goes. How the developers of the firmware can continue to screw up and still keep there jobbs is a good question for me.

Best regards.