I also think the ARP entries between the modem and the RV220W may have something to do with not updating effectively. At some point, it may have the unwanted IP while other times it may have the wanted IP.
Dyn updater unable to get ip addresses will try later update#
Not only this, but if it would update correctly, it may have the effect of having 2 DHCP services on the WAN. You should be able to run a packet capture on the WAN of the router to see this. 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. It also cannot supplement the VPN passthrough. 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. Additionally, the protocol passing is very dependent on the ability to traverse the firewall of the upstream router. Typically, routers are not behind a double-nat scenario.
I would double check to make sure the background client is disabled and then apply the DynDns to the router again. It can take some time for that to resolve. I'm hoping that I'm just missing something in the set up to get it to return 71. or whatever it is today and tomorrow.Ī lot of times if you use the Client APP then the router function, it can be considered "blocked as abuse". Without knowing a valid global IP address, it's a pretty useless function. 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. 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). It's smart enough to realize it's behind some other devices and figure out the actual IP address. 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.Īs I said, I can get around it by running the ap on a computer. That's not the way the DSL modems around me work or the way the cable modems work. 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 is the address assigned to the WAN port by the modem. Problem is, instead of a public IP it returns a 198.x.x.x address. Well, yes, it has to be enabled to get any response. So, is there a way to get the RV220W to return the true external IP address, or is it stuck returning a private address?
Since this works, and the RV220W doesn't, there is some difference between the Cisco implementation and the implementation. In some cases, however, there isn't such a computer to leave dedicated to running the separate program. That works in some locations if I have an always on computer to load the application to. If I do the same thing but use the 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. Doesn't matter for normal web access but trying to set up a VPN tunnel fails due to the inaccurate IP address.
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.
0 kommentar(er)
