I have an RV180 and an RV180W at two sites - with the aim of setting up a VPN between the sites.
I am pleased to see that NoIP is now supported - so I was looking forward to automating my working configuration so I no longer need keep track of IP addresses.
To my dismay it did not work.
Closer inspection showed that NoIP recorded the IP address of the DDNS domain name as 192.168.x.x - in other words, the input side of the edge router.
My configuration at one of the sites has to put the RV180 on the LAN side of the edge router - because reconfiguring the cable router is not an option. However the network supplier has no issue with recoding the router to put the RV180 LAN port in the DMZ so, according to the Cisco documentation, there should be no issue.
Indeed if I manually set the VPN tunnel IP address to the WAN (internet facing) IP address then all does work fine.
I checked with NoIP and the issue is that the Cisco implementation of the DDNS update client chooses to send NoIP its 'WAN' address rather than leave the parameter blank. If the IP address parameter is supplied in the update request then NoIP uses the supplied parameter. If no IP address was specified, the more usual way, then NoIP would read the Internet source IP from the HTTP handshake and would find the real internet-facing IP address - which is exactly what we want. Cisco's implementation supplies the WAN port IP address - which causes the problem.
The question is why it is not sufficient to leave out the IP address and let NoIP use the source IP. What is the use in a VPN scenario of setting a perimeter network IP address which can never be found on the internet by definition.
If there is a reason that is not obvious - then why not /and option to use the box WAN address OR to not specify an IP address so that the DDNS provider is left to work out the true internet IP address?
My configuration works fine as long as I externally set the DDNS lookup value. What I want to do is for the RV180 to do what it says it does and set the internet address correctly.
Is this a Cisco firmware issue - or is there a way of forcing the update system to do what is needed?