MikroTik Remote Access Behind CGNAT

Summary CGNAT (Carrier-Grade NAT) lets an ISP share one public IPv4 address across many subscribers, which conserves scarce addresses but breaks inbound connections — so port forwarding to a MikroTik router behind it simply does not work. Because the router has no reachable public address, the reliable fix is to flip the direction: have the router dial out to a rendezvous point you control. This guide explains what CGNAT is, how to detect it, and how to manage MikroTik routers behind it using outbound tunnels.

What Is CGNAT?

CGNAT is a second layer of network address translation run inside the ISP’s network that maps many customers onto a small pool of shared public IPv4 addresses, typically handing each subscriber a private address from the 100.64.0.0/10 carrier range instead of a real public IP. It exists because the world ran out of free IPv4 blocks years ago: rather than buy increasingly expensive addresses, most fixed-wireless, mobile, fiber, and satellite providers now place subscribers behind a shared gateway. Your MikroTik still gets internet access and can initiate outbound connections normally — but from the public internet’s point of view, your router does not have an address of its own. (Carrier-grade NAT — Wikipedia)

How does CGNAT break inbound access to a MikroTik?

Normal port forwarding assumes your WAN interface holds a public IP that the rest of the internet can reach. Under CGNAT that assumption fails twice over. First, your WAN address is private (often 100.64.x.x), so a forwarded port on your MikroTik points at an address nobody outside the carrier can route to. Second, the real public IP sits on the ISP’s master NAT device, which is shared with dozens of other subscribers and will not forward an arbitrary inbound port to you — you do not control it. (Open Port Checkers — Why port forwarding fails with CGNAT)

The practical consequence for anyone running a fleet of routers is severe: you cannot Winbox, WebFig, SSH, or API into a customer’s MikroTik from the office, because there is no inbound path to it. A dynamic DNS hostname does not help either — it would resolve to the shared carrier IP, not to your router. This is the same wall that Starlink users hit, which we cover in detail in our Starlink IP changes case study.

How do you tell if a MikroTik is behind CGNAT?

Check the address on the WAN interface and compare it to the public IP the connection actually shows to the internet. In a Winbox or WebFig terminal:

/ip address print

If the WAN interface holds an address inside 100.64.0.0 – 100.127.255.255 (the 100.64.0.0/10 shared range), 10.0.0.0/8, or another RFC1918 private range, you are almost certainly behind CGNAT. Confirm by comparing that address with what an external “what is my IP” service reports: if they differ, a carrier NAT sits between you and the internet. A traceroute that shows one or more private hops before the first public hop is another strong signal. (oneuptime — How to detect if you are behind CGNAT)

How do you manage MikroTik routers behind CGNAT?

The durable fix is to stop trying to connect in and instead let the router connect out to a rendezvous point with a stable public address. Because the outbound connection is initiated from behind the CGNAT, the carrier’s NAT happily allows it — the same way your browser reaches any website. Once that tunnel is established, you reach the router back through it. There are four common ways to build this, each documented in its own guide:

A self-hosted VPN to a VPS is the classic approach: a cheap Linux VPS with a public IP acts as the meeting point, and each MikroTik dials in. WireGuard is the modern default — fast, low-CPU, and tolerant of the address changes that come with CGNAT and dynamic IPs. The broader VPS-based management guide covers the same idea with other tunnel types.

A managed mesh VPN removes most of the manual plumbing. Tailscale and ZeroTier both provide a control plane that handles NAT traversal and key distribution for you, so a router behind CGNAT joins the network with almost no per-device configuration.

A TR-069 / ACS platform is the telco-standard option when you operate at scale: the CPE opens an outbound session to an auto-configuration server, which then pushes config and firmware. This is purpose-built for managing subscriber devices that live behind carrier NAT.

A purpose-built management cloud combines the outbound-tunnel idea with monitoring and access control in one place, which is the model MKController’s NATCloud uses.

Tips

• IPv6 often sidesteps CGNAT entirely. If your ISP assigns a routable IPv6 prefix, you may be able to reach the router over IPv6 even while IPv4 is trapped behind carrier NAT — but only if every hop in your management path also has IPv6.
• Always set a keepalive on outbound tunnels (for example persistent-keepalive=25 on WireGuard) so the carrier does not silently drop the idle NAT mapping.
• Some ISPs sell a static or public IPv4 address as a paid add-on. For a single critical site that can be simpler than a tunnel; for a fleet it does not scale on cost.
• Never expose Winbox, WebFig, or SSH directly to the internet as a “workaround.” Behind CGNAT it would not work anyway, and on a real public IP it is a standing invitation to attackers.

FAQ

Does a dynamic DNS service fix CGNAT? No. Dynamic DNS only updates a hostname to point at whatever public IP you have. Behind CGNAT that public IP belongs to the carrier and is shared, so the hostname cannot reach your router.

Is CGNAT the same as the NAT on my own router? No. Your router’s NAT translates your private LAN to your WAN address, and you control its port-forward rules. CGNAT adds a second NAT inside the ISP that you do not control, which is why inbound forwarding breaks.

Can I just ask my ISP to turn it off? Sometimes. Many providers offer a public or static IPv4 address for a fee or on request. Availability and price vary widely by carrier and region.

Take the next step

Building your own tunnel for one router is straightforward. Doing it across dozens or hundreds of MikroTiks — each behind a different CGNAT carrier, with keys to rotate and VPS configs to babysit — is where the operational cost stacks up.

MKController’s NATCloud is built for exactly this. Each MikroTik comes online over an outbound tunnel to the control plane, with no public IP, no port forwarding, and no per-device VPS edits required. You get centralized monitoring and secure remote access to every router, even the ones buried deep behind carrier NAT.

Start your free MKController trial