Dynamic DNS returns wrong address

[jrusselltx]

I think I'm missing a basic step here.  In setting up a RV220W device behind either a cable modem or a DSL modem, the address that is being returned is not the public IP address of the modem, but rather the private IP address assigned by the modem to the RV220W.  Doesn't matter for normal web access but trying to set up a VPN tunnel fails due to the inaccurate IP address.

If I do the same thing but use the dyndns.com application on a computer behind all of this (connected on the private LAN of the RV220W via cable), it reports the external IP address correctly.  That works in some locations if I have an always on computer to load the application to.  In some cases, however, there isn't such a computer to leave dedicated to running the separate program.

Since this works, and the RV220W doesn't, there is some difference between the Cisco implementation and the dyndns.com implementation.

So, is there a way to get the RV220W to return the true external IP address, or is it stuck returning a private address?

[Tom Watts]

Hello James, have you enabled the dyndns service on the router?

Navigate networking -> Dynamic DNS

-Tom

[jrusselltx]

Well, yes, it has to be enabled to get any response.  Problem is, instead of a public IP it returns a 198.x.x.x address.  That is the address assigned to the WAN port by the modem.  It seems to me the assumption on the part of Cisco is that the modem (or whatever device the box is attached to) is somehow giving the router a valid external IP.  That's not the way the DSL modems around me work or the way the cable modems work.  They all contain their own routing function, if that's the right term, and have a public IP that shows on the interface side of the modem but then have a private address for their LAN side.

As I said, I can get around it by running the dyndns.com ap on a computer.  It's smart enough to realize it's behind some other devices and figure out the actual IP address.  In this case, there is one private sub-net (on a /224 mask) between the modem and the Cisco box and another, different private sub-net (also on a /224 mask).  That just says it's possible to determine the external IP from the inside, but the Cisco box doesn't seem to be able to do that.

Without knowing a valid global IP address, it's a pretty useless function.  I'm hoping that I'm just missing something in the set up to get it to return 71.114.236.xxx or whatever it is today and tomorrow.

[Tom Watts]

Are you running the Dyn Update Client App on the computer inconjunction witht he DynDns on the router?

-Tom

[jrusselltx]

No, it's turned off on the router now.  I tried to get that working with the computer off but could only get the bad IP address out of the router.  So I turned it off on the router and back on with the computer.

[Tom Watts]

A lot of times if you use the Client APP then the router function, it can be considered "blocked as abuse". It can take some time for that to resolve.

I would double check to make sure the background client is disabled and then apply the DynDns to the router again.

Typically, routers are not behind a double-nat scenario. Additionally, the protocol passing is very dependent on the ability to traverse the firewall of the upstream router. I would likely suspect even if the dyndns updated to your satisfaction, the VPN likely would fail as it has to translate the NAT in which the protocols will fail.Unfortunately, the DynDns is not a NAT traversal feature nor could it supplement it. It also cannot supplement the VPN passthrough.

I suspect when the DynDns request is being sent by the RV220W, when it hits the update server, the response is not making it back to the RV220W.

You should be able to run a packet capture on the WAN of the router to see this. Not only this, but if it would update correctly, it may have the effect of having 2 DHCP services on the WAN. At some point, it may have the unwanted IP while other times it may have the wanted IP. I also think the ARP entries between the modem and the RV220W may have something to do with not updating effectively.

-Tom

[jrusselltx]

I'm not sure what you are saying makes sense:

The modem firewall is turned off completely.  It's only function (besides receiving the data signal and translating it into ethernet) is the NAT between the Internet IP and the first private network.There is no way to simply have the modem (or modems in this case since one version is a DSL modem the other is a cable modem) pass the "real" IP to the router.  I've tried that on 3 different modems and it just doesn't work.  The ISPs system won't support that and, according to them, it is impossible to move back to that kind of implementation in their system.  But the Cisco router is only seeing a single NAT function between it and the external IP address.

The second NAT is being done by the router.  It seems to me, as a real laymen in this particular topic, that if the dyndns program can figure this out from behind the double NAT, it ought to be easier for the router.  I have no idea how they do their "magic" but it is clearly superior to whatever Cisco is doing:  dyndns can return the actual IP address to their system, the Cisco box cannot.

The Cisco implementation looks to me (based on how it sends the "IP address" to dyndns.com) to simply look at whatever address has been assigned to its WAN port by the upstream DHCP server.  There doesn't seem to be any intelligence in that decision process.

I don't see any evidence that the WAN IP address of the Cisco router is ever changing.  There isn't any reason for it to change since it is getting it from the DHCP server in the modem.  This isn't a new system and it has been working correctly for 4 years.  Previously we had a different brand of router/VPN and separate wireless access point.  That router died and so the goal was to update the hardware and I had hoped the Cisco dynamic IP address function would actually work.  Seems to me that is the definition of what it is supposed to do.  Cisco seems to assume that the WAN port is going to get a valid global IP address somehow.

On this particular implementation (at my house) I am able to dedicate an always on computer to the dynamic DNS function so I've just gone back to that.  Even behind the double NAT it has no trouble feeding the correct IP address to dyndns.  But I have other locations where we'd have to actually add a computer just to run the dyndns service all the time to keep the VPN alive and I was hoping the Cisco system had correctly implemented the function.  It means I can use the single box as router, VPN tunnel creator, dynamic dns controller, and wireless access point.  A neat reduction in hardware, electricity, size of equipment, etc.

Guess that's not the case so I'll keep looking for a system where it works, or bite the bullet and add a dedicted computer.  Thanks for trying to help.