Reaching a changing address

You want to reach your own network from outside. For that you need an address, and that address changes: many providers hand you an IPv4 address that can be different after a reboot or a maintenance window. Dynamic DNS solves it by letting a name follow the address.

Where it sits in the tool

The IP Cloud fields live in Management access, not under Services and tools. That is historical: they belong with what the router tells the outside world about itself. There are three switches.

IP Cloud DDNS

The router reports its public address to MikroTik and gets back a name of the form xxxxxxxxxxxx.sn.mynetname.net, based on the serial number. The script writes /ip cloud set ddns-enabled=yes.

Update time via IP Cloud

Takes the time from the same service. Useful on a device that may not or cannot use NTP. See System and time for the ordinary NTP client, which the tool enables by default.

Back To Home VPN

Only visible when DDNS is on. See ZeroTier and Back To Home.

Add the VPN block in the wizard and DDNS is ticked for you. Under VPN you fill in the public address or hostname that ends up in the client configurations; without a fixed IP you put your mynetname name there.

Checking that it works

/ip cloud print

You see your dns-name, the public-address the service sees you at, and when it last updated. If something is off, force an update with /ip cloud force-update.

Watch for the line that sometimes appears: when the address MikroTik sees is not the address on your WAN interface, something sits in between. Compare it with:

/ip address print

If that shows 192.168.2.10 on your WAN while /ip cloud print reports a public address, your modem is not in bridge mode and you are behind two layers of NAT. The name works, but it points at your modem and not at your router. Port forwarding then has to happen on that modem as well.

A DNS provider of your own

This is where the tool stops: there is no field for another DDNS provider. If you want a name in your own domain, at Cloudflare, at DuckDNS or anywhere else, that is not a checkbox but a script.

It can still go through the tool. Services and tools has the custom scripts list with a name, an interval and the source. Put a script in it that calls your provider's update URL with /tool fetch and give it an interval of, say, 5m; the script and its scheduler entry then end up in your configuration script. The contents of that script are yours to write, because every provider has its own URL and its own way of authenticating.

Why bother? Because a name in your own domain looks better in a client configuration, because you can move it to another line without touching every client, and because you are then not depending on a service run by MikroTik. That last one is the honest argument against IP Cloud: it puts something about your connection in a third party's hands.

What breaks behind CGNAT

More and more providers no longer hand out a real public IPv4 address, but one from a shared pool, usually in 100.64.0.0/10. That is carrier-grade NAT, and it means your line has no doorbell of its own.

DDNS keeps working in the sense that there is a name and that it resolves to an address. What does not work is incoming traffic:

• Port forwarding does nothing. The packet never reaches your router. See Port forwarding.
• A VPN server on your router cannot be reached. WireGuard, IKEv2, L2TP, SSTP: all of them wait for a connection that never comes.
• Let's Encrypt over the HTTP challenge fails, because port 80 cannot be reached from outside. See Certificates.

You recognise it by the address on your WAN interface falling inside 100.64.0.0/10, or by /ip cloud print reporting a different public address than your WAN interface has while your modem is in bridge mode.

What you can do about it, in the order that usually works:

1. Ask your provider for a public address. At many providers that is a setting in the customer portal or a phone call, sometimes for a small fee.
2. Use IPv6. Behind CGNAT you often do have a full IPv6 prefix, and then your router is simply reachable on an IPv6 address. See IPv6. The drawback: you then depend on IPv6 being available where you are coming from, and on many corporate networks and hotel Wi-Fi it is not.
3. Turn it around. Anything where your router dials out instead of waiting does work: Back To Home, ZeroTier, or a WireGuard tunnel to a VPS with a fixed address. See ZeroTier and Back To Home.

Together with VPN and port forwarding

A name is not access. That is the mistake made most often: enable DDNS, put the name in a client, and be surprised nothing happens. The name only produces an address. After that something still has to be listening on the router and the firewall still has to let it in.

For VPN that is automatic: the tool adds the firewall rules for the VPN ports itself from the VPN section. For other services you enter them yourself under Port forwarding, or under services on the router itself reachable from the internet in the Firewall section.

What you should not do is open your management ports to the internet because you now have a name. For management from outside, the VPN is the way: the tunnel first, WinBox after. See Going over a device once more.

Finally, check that the name does what you think, from a connection outside your own network:

:put [:resolve "xxxxxxxxxxxx.sn.mynetname.net"]

Read on: Remote access VPN, Port forwarding and Internet connection.