Investigation of a Private IP Leak on MikroTik

It is a sinking feeling when a routine reboot leaves you completely offline. Recently, my internet connection failed to establish after a restart, so I reached out to my ISP to figure out what was wrong. While troubleshooting the outage, their support team told me something completely baffling: my router was leaking private IP addresses, like 10.10.10.2 and 10.10.10.3, and internal MAC addresses directly into their network infrastructure.

For any home lab enthusiast or network admin, this sounds impossible. My network is behind a firewall, and Network Address Translation (NAT) is supposed to hide everything behind my public WAN IP. How did my sophisticated MikroTik router suddenly start forwarding untranslated internal traffic?

Let’s dissect exactly how this happened, why a broken gateway connection caused it, and how a seemingly “smart” feature created a catastrophic domino effect.

How the Leak Was Discovered

The detection happened because of two converging issues:

My Perspective (The Outage): From the inside, my network appeared partially broken. My local devices were receiving their DHCP addresses perfectly fine, but the connection to the provider’s gateway simply wasn’t establishing. I called the ISP to investigate the broken connection.
The Provider’s Perspective (Layer 2/3 Anomalies): When the ISP looked at my connection on their end, their security systems flagged anomalous traffic. They were seeing private subnets originating from my physical port. Because these packets were leaving my router completely untranslated, the provider’s equipment could see the raw source IP addresses of my internal servers and containers, and even my internal MAC addresses.

This wasn’t a physical cable loop or a switch error; it was a complete failure of the NAT masquerade rule. Here is why it broke down.

The Root Cause: The “Detect Internet” Domino Effect

In MikroTik, routing and firewall rules are highly interdependent. In my scenario, a minor routing failure cascaded into a complete NAT breakdown.

Domino 1: The Initial Gateway Failure

Due to an unrelated configuration issue on my end, my router failed to establish a successful connection to the provider’s gateway. The initial routing simply broke down, leaving my physical WAN connection in limbo.

Domino 2: The “Detect Internet” Trap

Because the gateway connection failed, the router was left trying to figure out what to do with the physical WAN interface. Here is where the fatal blow occurred. I had a feature enabled in RouterOS called Detect Internet.

This feature constantly pings a reliable external host to verify connectivity. If the pings fail, the router dynamically reclassifies the interface, essentially kicking it out of the WAN interface list and potentially treating it more like a LAN connection. Since my routing to the gateway was broken, the pings failed. The router decided my physical ISP cable was “dead” and dynamically removed it from the WAN group.

Domino 3: The NAT Failure

Virtually all default NAT configurations rely on interface lists. My masquerade rule was set up like this:

action=masquerade chain=srcnat out-interface-list=WAN

This rule translates internal IPs only if the traffic is leaving via an interface in the WAN list. When the “Detect Internet” feature dynamically removed my physical interface from that list, the condition for the NAT rule was no longer met. The masquerade rule silently disabled itself for that specific port.

However, my internal devices (like my NAS and Docker containers) were still aggressively trying to reach the internet. Without NAT active to catch and translate their packets into a single public IP, the router simply routed them as-is. My internal 10.10.10.x packets flowed directly out the physical cable into the ISP’s network, triggering the provider’s alarms.

How to Fix It and Prevent Future Leaks

If you ever find yourself configuring an advanced router like a MikroTik, you have to ensure your fail-safes are hardcoded, not dynamic.

Disable “Detect Internet”: In complex setups, automated “helper” features often do more harm than good. Disable the feature completely (/interface detect-internet set detect-interface-list=none) and rely on proper routing metrics instead.
Hardcode Interface Lists: Ensure your physical WAN ports are statically assigned to the WAN interface list (/interface list member). Your NAT rules depend entirely on this list remaining stable to protect your internal IP addresses from leaking out.

Modern routers give you the power to build incredibly robust networks - and occasionally, the ability to accidentally bypass your own NAT rules. When an ISP sees your private IPs, check your interface lists and be very wary of “smart” features that alter your configuration dynamically behind the scenes.