MikroTik

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 have been seeing more and more cases of things not getting responses from IP cloud. Erroring out. Or just looking like the service is not running.

I just took an OLD wAP AC that NEVER was on IP cloud from 6.40.1 to 6.47.4.

I even defaulted the unit before trying to turn on IP cloud.

Still isn't getting a response.

Anyone else seeing anything similar?

I have been emailing with Support about a site that was on 6.40.8 and i can't update it as I need to go there physically. And its been almost 2 weeks of one email a day.


####
[admin@MikroTik] /ip cloud> /ip cloud print
ddns-enabled: yes
ddns-update-interval: none
update-time: yes
status: updating...
####

I have a new cap ac that was shipped with 6.44 and updated it to 6.47.4 before resetting the config into caps mode. I just ran the following and it worked fine.

I have a new cap ac that was shipped with 6.44 and updated it to 6.47.4 before resetting the config into caps mode. I just ran the following and it worked fine.

Code: Select all

/ip cloud set ddns-enabled=yes 

I have seen this across a few units now...

ddns is enabled.

[admin@MikroTik] /ip cloud> /ip cloud print
ddns-enabled: yes
ddns-update-interval: none
update-time: yes
status: updating...

Here is the output of a 6.40.8 unit that is not updating either.

[admin@mikrotik] > /ip cloud print
ddns-enabled: yes
update-time: no
public-address: 75.17x.xxx.xxx
dns-name: xxxxxxxxxxxxxxx.sn.mynetname.net
status: Error: request timed out

And since this router has 3 wAP ACs behind it... here is what the DNS cache looks like:

4 cloud.mikrotik.com 159.148.147.229

9 cloud2.mikr... 159.148.172.251
10 cloud2.mikr... 159.148.147.201

What can you see if you just traceroute the resolved cloud IPs? This should tell you whether it is a routing issue somewhere between you and the servers or an overload of those servers. I am running ddns update on two units since yesterday and never hit a pause (but I just had a look a few times during that time).

What can you see if you just traceroute the resolved cloud IPs? This should tell you whether it is a routing issue somewhere between you and the servers or an overload of those servers. I am running ddns update on two units since yesterday and never hit a pause (but I just had a look a few times during that time).

[admin@mikrotik] > /tool traceroute cloud2.mikrotik.com
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 75.17x.xxx.xxx 0% 4 15.7ms 13.2 9.2 15.7
2 174.111.73.61 0% 4 29.6ms 28.2 22.1 33.1
3 24.31.205.184 0% 4 13ms 12.7 9.2 16.1
4 24.93.64.180 0% 4 18.6ms 20.8 18.6 23.5
5 66.109.6.34 0% 4 23.6ms 26.1 19.7 40.7
6 66.109.5.125 0% 4 18.1ms 17.9 17.1 18.9
7 62.115.156.220 0% 4 24ms 22.9 19.1 27.9
8 62.115.125.190 0% 4 33.8ms 32.6 30.3 33.9
9 62.115.141.245 0% 4 143.1ms 141.7 139.4 143.1
10 213.155.134.51 0% 4 150.9ms 144.9 141.8 150.9
11 62.115.139.168 0% 4 152.4ms 154.9 152.2 161.3
12 62.115.136.77 0% 4 143.1ms 146.8 142.9 155.2
13 213.248.84.33 0% 4 146.3ms 144.9 141.5 146.3
14 100% 4 timeout
15 100% 4 timeout
16 100% 3 timeout
17 159.148.172.251 0% 3 145.8ms 144.8 143.3 145.8


[admin@mikrotik] > /tool traceroute cloud.mikrotik.com
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 192.168.10.1 0% 2 0.1ms 0.3 0.1 0.5 0.2
2 75.176.176.1 0% 2 11.7ms 12.3 11.7 12.9 0.6
3 174.111.73.113 0% 2 30.5ms 30.1 29.7 30.5 0.4
4 24.31.205.184 0% 2 15.9ms 15 14 15.9 1
5 24.93.64.180 0% 2 22.1ms 22.8 22.1 23.4 0.7
6 66.109.6.82 0% 2 20.9ms 27.2 20.9 33.5 6.3
7 66.109.5.125 0% 2 20.5ms 16.7 12.8 20.5 3.9
8 62.115.156.220 0% 2 22.4ms 25 22.4 27.5 2.6
9 62.115.125.129 0% 2 28ms 28 28 28 0
10 100% 2 timeout
11 80.91.254.90 0% 2 151.1ms 148.8 146.5 151.1 2.3 <MPLS:L=288,E=0>
12 62.115.139.172 0% 2 141.7ms 141.5 141.3 141.7 0.2
13 62.115.136.79 0% 2 140.1ms 140.1 140.1 140.1 0
14 213.248.84.33 0% 2 158.2ms 150.8 143.4 158.2 7.4
15 100% 2 timeout
16 100% 2 timeout
17 100% 1 timeout
18 159.148.147.229 0% 1 144.7ms 144.7 144.7 144.7 0

I used the packet sniffer and when you enable ip cloud on a new device it sends one udp packet to one of the addresses resolved by cloud2.mikrotik.com on port 15252. In my case it is sending data to 159.148.172.251 and 159.148.172.201. I tried on two different cap ac devices.

Once the request is made by the client the cloud server sends back a response. Each enable/disable should just be 2 packets.

I used the packet sniffer and when you enable ip cloud on a new device it sends one udp packet to one of the addresses resolved by cloud2.mikrotik.com on port 15252. In my case it is sending data to 159.148.172.251 and 159.148.172.201. I tried on two different cap ac devices.

Once the request is made by the client the cloud server sends back a response. Each enable/disable should just be 2 packets.

I have set up a firewall rule to log when that packet goes out on 15252. I see it go out. I have EXPLICITY allowed 15252 in and there is nothing coming in on that port.

I have shut off the firewall all together... no response.

This is ALL on hardware that is at least a few years old.

I have not seen this on anything I installed in the last year.

I have a CCR1009 which is almost 5 years old and it has been updating fine - I keep it current, so at one point was on 6.33 or earlier.

I just connected to a RB751G (8 years old) that had never had ip cloud enabled - running 6.47.3 and it updated fine.

I have a CCR1009 which is almost 5 years old and it has been updating fine - I keep it current, so at one point was on 6.33 or earlier.

My CCR is also about that old... but it has been kept current.

Nah OK here

I've just tried on a machine from 2016 or older (I don't know, I've inherited it in 2016 from the previous admin, factory-firmware: 3.04) and it works as well (running 6.45.9 now)... strange what you experience.

Updated a hEX that would not update with Ipcloud... Used 6.47.4

Ipcloud started working.

The wAP AC behind it... Nope.

Not that much of a fan of "works for me" posts but in your case, I'm in. And that just because you keep writing about your issue in atleast 3 topics without trying to debug it yourself, (hey, you did a traceroute yesterday, that's something! congrats.)
And yes, it works for me in an ancient RB2011 which is BEHIND another router.


So you figured out that you can reach the IP Cloud's IPs with that traceroute, now either something blocks you from reaching UDP port 15252 on those IPs or something blocks the response on its way back(?).
But as I recall you got a response in another topic from support in which they stated that they didn't receive anything from your equipment so I'm guessing you have a weird rule setup that catches that packet for port 15252 and sends it to space. Find whatever blocks it, setup firewall log rules etc.
Check your upstream router's config/firewall.
Trashing topics in the forum with this isn't very productive.
gotnat? pun intended.
And to be ontopic, answering your question/topic: No, no problem with IP Cloud.

I have set up a firewall rule to log when that packet goes out on 15252. I see it go out. I have EXPLICITY allowed 15252 in and there is nothing coming in on that port.

I understand you're nervous about it, so you may have written something else than what you actually intended to write - did you explicitly allow reception from UDP/15252? The communication looks as follows:
But still, "accept established" in input chain should normally be sufficient...

I also must admit that the first response took several seconds when I tried on several devices where I've never tried before. A wild speculation would be that the serial number is being sought in some database and there is some overload, so it could be that it takes too long for your device to wait for the response, or maybe your affected serial numbers are not in the database due to some glitch.

If you can see the request packet leaving on the sending router, and Mikrotik support says they've never received it, there may be something further in the path blocking its delivery.

At this stage, I'd create a static DNS entry on the sending router, redirecting cloud.mikrotik.com and cloud2.mikrotik.com to one of the public IPs I can sniff at, and see whether the request packets arrive there when you toggle the update-ddns between yes and no. As @Znevna says, it may be your own firewall rules on the NATing device, especially since you say that the NATing device itself can update the DDNS but those on its LAN can not.

And last, the same symptom may have distinct root causes at different sites.

routers and CHRs are eligible for IP Cloud (sorry no x86 installs). If you try to get that - you can check the status of the ordeal.
Fastest way is to use

/ip cloud force-update

instead disable/enable - as the first will attempt to re-auth with the server, the second will attempt to send a packet to unsubscribe you from the service (in case you wanted to use the service, but now want to remove trace of it and your IP address)

Znevna,

I have set up a rule to look for the 15252 in and out. They are set to log. On one router I will see it sending packets every minute with no response.

I have set up a static entry in dns to force cloud2 to the IP address that was listed here. Support also gave me the same IP address.

I have also seen the problem across several different routers.

Believe me... I have been trying to debug it myself. And the response from Mikrotik was about 1 router. I spent yesterday in 5 other ones.

On the last site I was working on.
There are 3 wAP AC running as caps-man APs.
They were all on 6.40.1.
I updated them to 6.47.4 and tried turning on /ip cloud.
When that didn't work... I factory defaulted one. Set up it's clock and ntp.
Got in it's DNS and put the results here.
No joy.
Then I gave in and updated the hEX that was running as a router.
Now this hEX had also not been working with IP cloud... And it's results are here.
After updating it to the current routerOS... Ip cloud worked.
The wAP behind still is not.

wAP behind the hex... (running as a cap)
[admin@MikroTik] > /ip cloud print
ddns-enabled: yes
ddns-update-interval: none
update-time: yes
status: updating...

The hEx infront. (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: xxxxxxxxx.sn.mynetname.net
status: updated

routers and CHRs are eligible for IP Cloud (sorry no x86 installs). If you try to get that - you can check the status of the ordeal.
Fastest way is to use

/ip cloud force-update

instead disable/enable - as the first will attempt to re-auth with the server, the second will attempt to send a packet to unsubscribe you from the service (in case you wanted to use the service, but now want to remove trace of it and your IP address)

I do not have any x86 installs.

I have tried disabling IP-Cloud then enabling. Didn't have any effect.
I am hitting Force-Update when I am looking at Torch and taking screen shots. Also have the port and protocol set to log from OUTPUT chain and INPUT chain in firewall.

All these Mikrotik Routerboards aside from the wAP AC behind the one router have been using IPCloud 1 for several years and recently stopped updating.
Hardware references and exported terminal data from:
CRS125
hEX
750 G r3
wAP AC

The issue as I addressed is that I have not changed anything... and suddenly devices that had IP Cloud working on cloud.mikrotik.com (old cloud) suddenly stopped working.

Do the devices all share the same ISP?

All of my tests have been on Comcast, from various locations on their network.

Do the devices all share the same ISP?

All of my tests have been on Comcast, from various locations on their network.

Nope.

Geographically diverse too.

All over the US.

Some are on Comcast. Some on Verizon. Some on Spectrum. Some on ATT Cellular. etc etc etc.

The issue where OLD routerOS and IPCLOUD doesn't work has become something where support has just told me "Well you have to Upgrade". As some of those sites have configurations that change between the current ROUTEROS and the OLD RouterOS (SLAVE MASTER and bridging) I am hesitant, to HIT UPDATE without someone on site.

The other problem and more a... "Why did that happen"... will be when you update 2 devices at the same PHYSICAL LOCATION and one updates IPCloud and the other Doesn't.

Like I typed... I spent all day looking at different sites and some had the same problems and other had others. SO it was getting to the point where I would just "THROW IT AT THE WALL AND SEE WHAT STICKS."

But support took a much more active role this morning and I sent them a bunch of serial numbers and rif files.

Hello to all,
few hours ago two routerbooards of mine stopped upfating ddns IP ... even Public IP adress does not appear in ip-cloud window ... till then everything worked correctly for years ...
I reset configuration on one , downgraded from 6.48.3 down to 6.47.10 but nothing changed (disabled ip-cloud before downgrade/upgrade) ... one more thing: this one even does not show it's own DNS name ... both public-adress and dns-name fields are blank (?!) ... could accept public-addres not showing up but it's-own-dns-name ?!?!
I kindly ask for help/support ...

Thank you in advance
BR
Tonci

.. even netinstall does not help ....

Hello to all,
few hours ago two routerbooards of mine stopped upfating ddns IP ... even Public IP adress does not appear in ip-cloud window ... till then everything worked correctly for years ...
I reset configuration on one , downgraded from 6.48.3 down to 6.47.10 but nothing changed (disabled ip-cloud before downgrade/upgrade) ... one more thing: this one even does not show it's own DNS name ... both public-adress and dns-name fields are blank (?!) ... could accept public-addres not showing up but it's-own-dns-name ?!?!
I kindly ask for help/support ...

Thank you in advance
BR
Tonci

I have same problem too.

iArpi

I am also experiencing issues with IP Cloud at the moment.

I also have the same issue since few hours. I have 6.48.2 installed on my hex.
No public ip address is being shown in ip cloud. Screenshot is attached.

I am having the same problem today with more than 20 routers.
Versions > 6.45.3 and up to 6.48.3. Makes no difference.
Tried reboot, updating no luck.
A similar thing happened when the cloud servers changed a time ago. The cloud IP started working a day later.

I have the same happen today. I have 6.47.8 on RB2011UiAS.
IP cloud not update and status always updating...
Try Force Update, Disable/Enable DDNS not working.

I also have the same issue since few hours. I have 6.48.2 installed on my hex.
No public ip address is being shown in ip cloud. Screenshot is attached.

how about right now?still problem?
because I have the same problem untill right now

Same here with 6.47.10 long-term

I also have the same problem.
The ip won't update even if I force update

Yup, it's dead, the DDNS part atleast. I thought it was something about 6.47.10, but no, it's not version related.

i'm also having same issue, IP cloud not updating.

Version 6.48

The cloud has not worked for me since 06/03/2021

Yes for mee too. From different routers, different ISPs, different IPs..... hundreds of vpns on dinamic IP is papaaaaa.....

I wrote to support, last night, till yet no answer.

it just worked for me

Still doesn't work.

We suffer a problem with IP/Cloud since the night between June 3rd-June 4th.

It kind'a started working again an hour ago, but now, after restart , not any more ... too many vpn tunnels down ...

Still doesn’t work!!

Wasn't working Thursday when I asked 2 routers.

This morning both those routers worked and the 3 I did today worked.

Guessing it was Tik's server again.

Not working for me either.

For me it is also not working, i think indeed the server of mikrotik is down.

viewtopic.php?f=2&t=178260
viewtopic.php?f=2&t=178256

Mikroitk's revolvers are still working, you can add a conditional rule to get your resolution working again:

159.148.147.201
159.148.172.251

Nice, how access remote device that use cloud... for update the cloud...
Very brillant copy & paste solution...

***********************

The domain mynetname.net expire on 2022-04-29T08:21:38Z
Simply mikrotik forgot to pay the $35 annual fee to publicdomainregistry.com

Stop speculating and writing idiocy and wait for the service to restore.

Hi rextended & excession, are you saying this added bit to a config will fix the problem temporarily?
/ip dns static
add forward-to=159.148.147.201 regexp=".*mynetname\\.net" ttl=10m type=FWD

Hi rextended & excession, are you saying this added bit to a config will fix the problem temporarily?
/ip dns static
add forward-to=159.148.147.201 regexp=".*mynetname\\.net" ttl=10m type=FWD

If you have a local Tik doing DNS for you (or another DNS server you can configure conditional DNS forwarders on), It will force any name resolution attempts for mynetname.net to go straight to Mikrotik's servers, which will correctly resolve the name for you. If your monitoring is down because of name res it will sort that out. (You may need to clear your DNS cache on both your router and your device.)

If you have written fw rules on remote machines that depend on mynetname.net to know if they should let you access them, it's not going to help with that.

Give it a shot and see.

Done, crossed my fingers will disable it when mynetname comes back online but will be there ready for the next time LOL

Make Mikrotik support multiple dynamic DNS providers

If someone had a bit of cunning they would use multiple services between different providers,
rather than more than one service from the same, and rather than only one...

Nice, how access remote device that use cloud... for update the cloud...
Very brillant copy & paste solution...

***********************

The domain mynetname.net expire on 2022-04-29T08:21:38Z
Simply mikrotik forgot to pay the $35 annual fee to publicdomainregistry.com

Stop speculating and writing idiocy and wait for the service to restore.

we have proplem with cloud mynetname.net today

Make Mikrotik support multiple dynamic DNS providers

I did.

Mikroitk's revolvers are still working, you can add a conditional rule to get your resolution working again:

159.148.147.201
159.148.172.251

Code: Select all

/ip dns static
add forward-to=159.148.147.201 regexp=".*mynetname\\.net" ttl=10m type=FWD

Thanks i have lost VPN client connection, this script work great, hope they fix soon

https://puck.nether.net/pipermail/outag ... 13806.html

2021-09-07T15:37:37Z
Now is working again.

It seems IP Cloud is not working again (?!)
checked on several independent routers/isp's/ ...

Yes it dosnt work.

I just wrote to support.

started working now ... hope it remains stable ...

Wouldn't it be nice if there was a status at the top of this forum.

"Mikrotik Cloud Status : _______"

Why on the forum?
They should have a services status on the main website.

Why on the forum?
They should have a services status on the main website.

Agree. Or perhaps some backup host someplace else for geo-redundancy. Not asking 5-nines here.

IPCloud working?

IPCloud working?

Broken here as well.

IPCloud working?

Doesn't work anywhere. I've got 238 routers lying around.

Yes, it's down

Confirm, it does not work

Commenting in 2 years old topic: confirmed.

Why on the forum?
They should have a services status on the main website.

Agree. Or perhaps some backup host someplace else for geo-redundancy. Not asking 5-nines here.

Well, they should have a status page. I'd suggest Dude and function to update the web site

https://github.com/louislam/uptime-kuma

It allows to create dashboards. Add status messages. MikroTik team - have a look. It is free.

Looks like they got it going again?