Debugging a Site with IP Cloud (site LONG)

Solved:
From support:

"Hello,

We had some issues with the cloud servers in the past weeks, but if the same issue happens again, please let us know.

Best regards,
######"


I appreciate the help some are trying to provide with the other thread...
I think it might be easier to follow if I have a separate thread for a site.

So lets try this site Named LONG.
Hardware
Router :750G R2
CAP: wAP G-5HacT2HnD

The Router was on 6.40.8 since the CVE of 2018. The router had been using IP Cloud to update its external IP. When I connected to it yesterday... ip cloud was not working and kept showing error request timed out.

I logged into the wAP running as a cap. It was on 6.40.1.
I updated it to 6.47.4
I then DEFAULTED IT.
Logged back into the wAP and set its ip-cloud to on. I also manually set up sntp and clock to make sure they were right. And if I hit check for updates it can see that it is up to date and bring in the change log.
Here is the output:
[admin@MikroTik] > /ip cloud print
ddns-enabled: yes
ddns-update-interval: none
update-time: yes
status: updating...

I have tried disabling IP Cloud
[admin@MikroTik] > /ip cloud print
ddns-enabled: no
ddns-update-interval: none
update-time: yes
status: failed to connect

Then turned it back on.

Now to look at the wAP's DNS cache... you see this
[admin@MikroTik] > /ip dns cache print
Flags: S - static

NAME TYPE DATA TTL

0 cloud2.mikrotik.com A 159.148.172.251 1h34m34s
1 cloud2.mikrotik.com A 159.148.147.201 1h34m34s

NOW MOVING TO THE ROUTER.
The router was running 6.40.8 and was showing "request timed out" under IP cloud
The 750G r2 was updated to 6.47.4
It IS WORKING.

Now this is all at the same site with the WAP Directly Connected to the router.

Here is the output of the router.
[admin@mikrotik] > /ip cloud print
ddns-enabled: yes
ddns-update-interval: none
update-time: no
public-address: 75.17x.xxx.xxx
dns-name: xxxxxxxxxxxxx.sn.mynetname.net
status: updated

Here is the DNS Cache
34 cloud2.mikrotik.com A 159.148.172.251 1h29m16s
35 cloud2.mikrotik.com A 159.148.147.201 1h29m16s

Now as you can see... both routerboards at the same physical location resolve cloud2 the same.

Yet one IPCloud is working and the other isn't

The information in this post is about THIS SITE ONLY. The other post turned into me putting results from several sites in one thread. Hopefully if I keep one train on one set of rails... it might be easier to find a problem.

The issue is that I saw various problems on MULTIPLE SITES and HARDWARE... and was trying to find a common problem.

But the site above has ONE unit that is updating IP cloud and ONE that is not.

Thanks again to everyone looking at this and trying to help.

yay, another useless topic for the same issue.
@sindy suggested something in the OTHER thread, did you do it?
On your devices that don’t work, point cloud.mikrotik.com and cloud2.mikrotik.com to another public IP where you can monitor incoming packets and see if you receive any UDP packet on port 15252 on that IP from your devices when you enable/disable, force-update etc IP Cloud DDNS. If you don’t, something in your network blocks that, as previously said in the OTHER topic.
Stop creating more of these, please.

Znevna,

Thanks for the help. I will keep it in mind if you ever have a question about something I have seen before.

Now since the “useless thread”, support took a much more active role and got one site working. No explanation as to how or why it started working. They also asked for multiple Rif files which were provided.

Now as for the trouble shooting in the other thread… yes I was getting very frustrated with several site not updating anymore without any warning.

Yes I setup firewall counters to show the packets leaving to go to IPCloud.

Yes I setup firewall counters to show if they came back.

Yes I opened torch and copied the output.

Yes I showed traceroutes to the various IPs.

Yes I manually set a DNS entry.

Yes I tried to enable and disable cloud. Even reboot inbetween.

I did a lot of different things trying to fix this as it cropped up across 7 sites at once.

And, you know… you could just skip over it…

Since you didn’t understand the suggestion by @sindy with the static DNS entry to some other public IP to which you have access instead of the MikroTik ones, you can replace almost all of the above “yes, I did” with “No, I did not” and any further “debugging” seems pointless.
Cheers and good luck.

When support gets back to me with why a site that didn’t work all day Tuesday and Wednesday… suddenly started working this morning (Thursday) at about 7AM… Which didn’t work at 4AM… I will let you know.

From support:
“Previously there was not any IP, the device was not yet authenticated.”

Znevna,

This one’s for you…

From support:
"Hello,

We had some issues with the cloud servers in the past weeks, but if the same issue happens again, please let us know.

Best regards,
#####"

Don’t forget to mention it in all your other topics too ^^.
Worked and still works fine here.
I don’t rely only on one ddns service where it is needed anyway, so meh.
Thanks for the update tho’.
Cheers.