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.
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.
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).
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’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.
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.
/tool sniffer packet> print brief
# TIME INTERFACE SRC-ADDRESS DST-ADDRESS IP-PROTOCOL SIZE CPU FP
0 3.463 bridge 192.168.69.5:35003 159.148.147.201:15252 udp 96 0 no
1 3.533 bridge 159.148.147.201:15252 192.168.69.5:35003 udp 102 0 no
/ip cloud> print
ddns-enabled: yes
ddns-update-interval: none
update-time: yes
public-address: Y.Y.Y.Y
dns-name: XXXX.sn.mynetname.net
status: updated
warning: Router is behind a NAT. Remote connection might not work.
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 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:
[me@MyTik] > tool sniffer quick ip-address=159.0.0.0/8 interface=ether1
INTERFACE TIME NUM DIR SRC-MAC DST-MAC VLAN SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE CPU FP
ether1 59.844 1 -> B8:69:F4:F9:73:65 5C:F1:DC:EF:8A:7A 192.168.5.105:33036 159.148.172.251:15252 ip:udp 96 0 no
ether1 59.888 2 <- 5C:F1:DC:EF:8A:7A B8:69:F4:F9:73:65 159.148.172.251:15252 192.168.5.105:33036 ip:udp 102 0 no
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)
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
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.