I have enabled IP > Cloud, and I expected it would auto-update given dns-name when my public IP address changes, based on reading relevant documentation. Quote:
ddns-enabled (yes | no)
If set to “yes” then router will send an encrypted message to the MikroTik cloud server. Server will then decrypt the message and verify that sender is an authentic Mikrotik router. If all is OK then server will create a DDNS record for this router and send response to the router. > Every minute the cloud service on the router will check if external IP address matches the one sent to server and will send encrypted update to cloud server if IP address changes.
Bolded part is what I am having issue with. My public IP changed several times, since my cable-based ISP forces DHCP lease expiration every several days. This feature was enabled for more than a several weeks now, and it never did self-update. Forcing update by issuing /ip cloud force-update works as expected. Of course, I could script it to run frequently via scheduler, but I doubt that would be the right solution.
Here’s the relevant configuration of my router.
[admin@HomeMT] > /ip cloud export verbose
# jul/26/2015 12:49:19 by RouterOS 6.29
# software id = UWXX-ZKXX
#
/ip cloud
set ddns-enabled=yes update-time=yes
/ip cloud advanced
set use-local-address=no
[admin@HomeMT] > /ip cloud print
ddns-enabled: yes
update-time: yes
public-address: 188.2.xx.xx
dns-name: 2fxx02dfxxxx.sn.mynetname.net
status: updated
warning: DDNS server received request from IP 188.2.xx.xx but your local IP was 192.168.0.10;
DDNS service might not work.
indicates your router isn’t obtaining a route-able internet address on it’s WAN port. i.e. You router is behind another router with the WAN address of 188.2.xx.xx .
jebz, oh, that’s right, I forgot about my local network configuration. 192.168.0.10 is indeed assigned to my router by upstream DHCP on the cable modem, that holds actual WAN address. I will edit original question to remove suggestion about the warning.
Anyhow, my question still stands. Any ideas as to why Cloud isn’t auto-updating as advertised?
I am not sure that is how it is supposed to work. Besides, that’s exactly the case where use-local-address=yes option would come in handy, right? Let me quote the documentation again:
Every minute the cloud service on the router will check if > external IP address matches the one sent to server > […]
This pretty clearly says that a publicly visible IP will be compared to the IP previously sent and saved in DDNS record. Dynamic DNS service serves the purpose of mapping a changing IP address to a fixed DNS, and although I can think of a scenario where I would actually want to map a dynamic local IP to a DDNS record, far more useful scenario is keeping a publicly visible IP mapped to a DDNS record, wherever in the routing chain that IP resides.
If I am forced to have a public IP address on my wan interface, that defeats the purpose and ease of use of the Cloud option. I can totally see many users in the same position as I, where they have a cable, an ADSL or another ISP-mandated device that provides connectivity to their home network, in front of their MikroTik router, without possibility to change internal routing options of said device.
Yes it does sound like Mikrotik’s logic/algorithm is flawed, I have the same network topology as mrb (uplink connection is behind nat) and cloud ip doesnt auto update despite having use-local-address option.
Can I ask you guys to please update docs to reflect this stance? I believe others can get confused as well, due to ambiguous wording in docs.
I am already using full-blown DynDNS script for this very purpose. I just was hoping (beyond hope, as it turns out) that things just got much simpler for MikroTik owners.
Just so you know, I had the same problem with Cloud update.
The ISP gave a device that we can’t set as a simple ADSL modem, so we have DMZ to the Mikrotik behind it.
Unfortunately the ADSL is very bad, disconnects all the time, then the Mikrotik will not update the public IP for the Cloud.
So, solution:
new script
name: cloud
/ip cloud force-update
new schedule, every five minutes
event: cloud
And now we’re happy, it forces update every 5 minutes.
This is partially flawed logic- one of the nice features MT has builtin to their Cloud side code is its ability to recognize where the request is coming from and use that public IP if ROS is infact sending a private IP as the interface’s IP. ← this is GREAT functionality / thinking on MTs part.
however,
This also is one of the core benefits of the DDNS part of /ip cloud . If the cloud side is smart enough to set the DDNS to a non private IP (ie use the “received request from IP”) than the ROS side should be “smart” enough to run or force , force Update on some kind of schedule (even every 12h), just incase the user is not savey enough to know how to script and schedule a forced update. (and over recent years, clearly, MT has been making ROS / its Interface much easier so that the “non-tech” home users will adopt their great products - those users dont know how to script / schedule and frankly they also dont want to learn - unlike most of us.)
(btw, MT is doing this while still retaining+increasing all of the deeper power and functionality that we all love ROS for)
I understand MT / Normis ’ reasons and position in this ( just use /force update on a schedule if you are “an exception to the way /ip cloud ddns was intended to function” , if you have a private IP on your GW interface) - but this just seems like stubbornness in place of helpful/easier functionality (with no downsides that i can think of).
Just be sure that whatever DDNS service you use, that your account stays valid on that service (ie some of them make you “check in” every X number of months, if you are on their free tier) – i suggest using mikrotiks builtin “/ip cloud” service , if it works for your network setup (ie you dont have the issues we talk about in this thread)
