We have improved old IP Cloud backend, that will continue to serve older RouterOS versions.
Hi Janisk, thanks!
If my default setup does not allow external access to winbox, (or entire input chain) there is no security risk in using IP cloud correct?
It simply is an effective way to point to our external public WANIP (especially for those that need to connect to devices behind the router)?
.
Thankyou this is good news.
IP Cloud is made so that it does not pose a security threat. It will assign FQDN to IP address of your router. In RouterOS 6.43 or newer - it will have both A and Quad A entry maintained by the router (if both v4 and v6 connections can reach our backend).
It works for me on 6.44beta54 nicely, thank you!
The only problem with IPv6 (not MT’s fault) is that IPv6 AAAA has very limited usability. In IPv4 usually there will be some DST-NAT rules and will work directly off the IP address pointed to by A record. In IPv6 usually there will be some routing allowed, but referring to LAN host IP addresses directly. Hence AAAA record can only be used as a pointer where the whole /64 (or /60 or whatever prefix length) network wandered and one will have to deduct LAN hosts’ IPv6 addresses by hand.
Hello Janisk,
Is it possible to contact me via pm? I have a important Question to the Cloud function of the mirkotik that i don’t wont to discuss in public.
Peter
.. responding time: 10 Weeks if you write on this address….
PM response time: never, as they are disabled on this forum 
10 weeks are less than +infinity, if I remember correctly
There is a clear problem not being able to address different names for IPv4 and IPv6 addresses. My router in London, for instance, is under a provider that has CGNAT for IPv4 but gives a /56 of IPv6 addresses. As it is currently, for the other Mikrotik routers the name is useless, as the IPv4 address is non functional, while the IPv6 is perfectly reachable. Not even in the tunneled machines can I say
/ping <mysn>.sn.mynetname.net interface=sit1
, as the router pings using IPv4 even on interfaces that have no IPv4 addresses…
Computers are more clever and usually prefer IPv6 correctly.
I wonder if you could make the cloud server ping back to ensure that the the addresses are reachable before confirming the records. In any case I think you should provide .4sn.mynetname.net and .6sn.mynetname.net records.
This features from which version will start up?
I tested IPv6 once but that IPv6 address keeps in my IP Cloud record. How can I remove/clean that IPv6 entry only since I no longer use IPv6?
Update: Mikrotik support told me to disable / re-enable IP Cloud will remove no longer used IPv6 record.
Do I get a new domain name with the new Cloud service or if it still the xxxxxxxxx.sn.mynetname.net domains that are being used?
Domain names did not change, it’s still *.sn.mynetname.net
Contact via support@mikrotik.com
The e-mail has to contain proper question.
Domain names are *.sn.mynetname.net For IMv4 A record is added, for IPv6 AAAA record is added. If you enable DDNS feature router will attempt to connect via IPv4 and another connection via IPv6.
If you want to force the router to use only IPv6 to communicate with IP Cloud backend in the /ip dns cache set up a static entry cloud2.mikrotik.com with the proper IPv6 address. We are trying our best to not change the IP addresses without a good reason. In this case, the IPv4 connection will always fail.
The update works as fowllows - if no options are set - your DDNS address will be assigned to the source address of the packet received. That is not our concern if the address is not reachable as users may opt to register their local addresses, like 192.168.88.1 that is not globally routable.
Also, it is possible to check /ip cloud public-address (or public-ipv6-address) to see what source address packets coming from your router had.
One more important thing - if you have 2 or more connections, make sure you have proper configuration on your router for balancing or failover.
@janisk can you please check if you can open port 53 over TCP for the nameserver of *.sn.mynetname.net? (ns1.kissthenet.net and ns2.kissthenet.net)
These nameservers also doesn’t seem to support EDNS.
IP Cloud DNS server is not responding to TCP requests and in general, is outright denying access to TCP#53. All the EDNS features that rely on UDP will work. EDNS changes are there since February,
Cen i get some info regarding Ip Cloud. Since new version 6.44.1 Ip Cloud has features “use-local-address” if i tick that domain names is not going to change, it’s still *.sn.mynetname.net
It just uses local IP address (for example, in case of CGNAT), like you get local internal IP 100.72.56.9 from your ISP, and then it’s NAT’ed to public IP 93.125.75.34.
i thought that if i tick “use-local-address” is going to be local_address.sn.mynetname.net