Skip to content
Go back

Ditch Your ISP Router for MikroTik

By SumGuy 13 min read
Ditch Your ISP Router for MikroTik
Contents

Somebody Asked, So Here’s the Full Answer

A reader in Serbia left a comment on the MikroTik buying guide asking a very specific, very good question: can I keep the ISP’s GPON box plugged into the wall, run it as a dumb bridge or access point, and let a cheap MikroTik box handle the actual routing? Short answer: yes, almost always, and it’s the setup you want anyway. MikroTik gear is priced like a rounding error in Serbia compared to what North American ISPs charge for “premium” routers, so the hardware side is easy.

The hard part isn’t RouterOS. It’s a phone call, a login screen, or a support ticket that tells you what mode your ISP will actually let their box run in. Everything downstream, your VLAN tags, your firewall rules, whether port forwarding works at 2 AM when your partner is asking why the security camera app won’t load, depends on what your ISP hands you at the demarcation point. Get that part wrong and no amount of RouterOS skill fixes it.

This article is the missing middle step. The buying guide tells you which MikroTik box to buy and how to configure it once it’s in charge. This one gets you from “ISP router is in charge” to “MikroTik is in charge” without a truck roll or a hold queue that ends in a script reading.

The Three Ways Your ISP Can Hand Off the Internet

Every ISP setup falls into one of three buckets. Ranked from best to worst:

True bridge mode. The ONT (the box the fiber actually plugs into) stops being a router entirely and becomes a media converter: fiber in one side, Ethernet out the other, nothing else happening. Your MikroTik box does the PPPoE or DHCP negotiation directly with the ISP’s network and holds the public IP itself. This is the only mode where you get full, unfiltered control: inbound ports, your own firewall rules, WireGuard peers reachable on the actual public IP, IPv6 delegation that isn’t mangled by a second NAT layer. If your ISP offers this, take it and stop reading this section.

IP passthrough, router-in-bridge, or “DMZ host” mode. These are cousins, not the same thing, but they solve the same half-problem. The ISP box still does the PPPoE handshake and still routes, but it forwards the public IP through to one device behind it (usually via DHCP option or a dedicated DMZ setting) instead of NATing everything itself. Your MikroTik ends up with the public IP on its WAN interface, which sounds like true bridge mode, except the ISP box is still sitting in the path doing its own thing: its firmware, its quirks, its occasional reboot-for-a-security-update that drops your connection for ninety seconds without asking. It’s a workable stopgap, not a destination.

Double NAT. The ISP box keeps routing and NATing like it normally would, and your MikroTik sits behind it doing a second round of NAT on your internal network. This is the “it mostly works” option, and it’s also the option that quietly breaks things for months before you figure out why. Under double NAT: inbound port forwarding needs to happen twice (once on each box, and the ISP box’s UI is usually worse), UPnP and NAT-PMP get confused about which router they’re actually talking to and often just stop negotiating, any VPN endpoint you’re hosting (WireGuard, Tailscale exit nodes, whatever) needs forwarding rules on a device you may not fully control, and IPv6 prefix delegation, which is supposed to hand your router a routable block, usually just doesn’t happen because the ISP box ate the delegation and won’t share.

Double NAT is not a disaster for basic browsing and streaming. It becomes a problem the moment you want to self-host anything reachable from outside your house, which, if you’re reading a MikroTik article, is probably exactly what you want to do.

How to Find Out Which One You’re Stuck With

Nobody hands you a spec sheet for this. You have to go dig.

Check the ONT’s admin panel first. Log into the box (default creds are usually printed on a sticker, or a quick search of your ISP’s name plus “default password” gets you there) and look for a WAN section. Terms to hunt for: “Bridge Mode,” “PPPoE Passthrough,” “Transparent Bridge.” If the toggle exists and flips without complaint, you likely have true bridge mode available and nobody even needs to know you flipped it.

Look for a hidden superuser account. A lot of ISP-flashed firmware (this shows up constantly on Huawei and ZTE ONTs, which dominate the GPON market) ships with a customer-facing limited account and a separate technician or superuser account that unlocks bridge mode and other settings the ISP doesn’t want you touching. These credentials leak onto forums, Reddit threads, and .rs-specific tech forums, because ISPs reuse the same firmware across thousands of customers and someone always finds it. Search your ISP’s name plus the ONT model number plus “telecomadmin” or “superadmin,” those are the two account names that show up most.

Check whether your WAN IP is real or fake. Look at the WAN status page on the ISP box. If you see an address in the 100.64.0.0/10 range, that’s Carrier-Grade NAT (CGNAT), and it changes the whole conversation: your ISP isn’t giving you a public IP at all, they’re sharing one pool of public IPs across a bunch of customers behind their own NAT layer. Bridge mode doesn’t fix CGNAT. If you’re behind CGNAT, no amount of MikroTik firewall genius gets you inbound connections without a workaround like a provider-side static IP add-on or a relay such as Pangolin on a $5 VPS, where your home server dials out instead of waiting for anything to dial in. Check this before you spend money assuming bridge mode solves everything.

Just call and ask for bridge mode by name. This sounds like a coin flip and honestly it kind of is. Some ISPs will flip it in thirty seconds because their back-end supports it and the rep knows the setting. Others will insist it’s not possible because their script doesn’t have a line for it, even when the hardware clearly supports it. Ask twice, on different days, ideally get a rep who sounds like they’ve been there more than six months. Persistence pays off more often than it should.

The GPON Catch: Your ONT Is Not Just a Box, It’s a Login

Fiber gets annoying in a way cable and DSL never did. Your ONT isn’t a dumb terminal, it’s authenticated to the ISP’s OLT (the equipment at the other end, in their cabinet or exchange) by serial number, and often by a PLOAM password baked in at provisioning. That authentication is what lets the OLT know which subscriber line it’s talking to and how much bandwidth to hand it.

So you can’t always buy your own ONT and plug it in the way you’d swap a cable modem. Some networks let you drop in a compatible SFP ONT module in place of the ISP’s box, but only if you clone the original ONT’s serial number or PLOAM password onto it, which works on some networks (there’s a whole subculture doing this with GPON SFP modules and a serial adapter) and is a clear terms-of-service violation on others. It also solves nothing if the ISP box carries IPTV set-top traffic or VoIP on a separate VLAN, because now you’re rebuilding their entire service stack yourself.

The pragmatic move, and the one I’d actually tell the reader who asked: keep the ISP’s ONT. Don’t fight the authentication layer. Get it into bridge mode using the methods above, and let it do exactly one job: convert fiber to Ethernet. Everything else, routing, firewalling, VPN, DNS, becomes MikroTik’s problem, which is where you want the complexity anyway. Save the SFP-swap adventure for a rainy weekend when losing internet for six hours doesn’t cost you a spousal argument.

Turn the ISP Box Into a Free Access Point

Since the reader specifically asked about reusing the ISP hardware as an AP instead of a bridge, here’s the honest version of how that works and where it falls short.

Once your MikroTik is handling routing (from the ONT directly, or from the now-demoted ISP router), you can repurpose the old ISP router purely for its WiFi radios:

  1. Log into the ISP box’s admin panel.
  2. Disable its DHCP server completely, so it’s not fighting your MikroTik over IP leases.
  3. Disable routing and NAT, or if there’s no explicit toggle, disable the WAN connection entirely so it never tries to be a router.
  4. Connect a LAN port on the ISP box to a LAN port on your MikroTik switch (not the WAN port, this matters).
  5. Set the ISP box’s own management IP to a static address inside your MikroTik’s subnet, outside your DHCP pool, so it doesn’t collide with anything.
  6. Configure the SSID and password like normal. It now just broadcasts WiFi and bridges those clients onto your real network.

This genuinely works and costs you nothing. It’s also usually a downgrade. ISP-supplied WiFi radios are picked for cost, not performance, and a lot of them still only do WiFi 5 with mediocre antennas crammed into a case designed to also house a router, a switch, and sometimes a phone ATA. If you’re serious about coverage, a MikroTik hAP ax3 or a dedicated access point will outperform the ISP box by a wide margin, and the buying guide covers what to look for. But “free AP already bolted to my wall” is a perfectly legitimate stopgap, and there’s no shame in running it until the WiFi actually annoys you enough to upgrade.

Getting MikroTik to Actually Take Over

Once the ISP box is out of the routing business (bridged ONT, or demoted to AP-only with a separate bridged device upstream), point your MikroTik’s WAN port at it and configure the connection type your ISP actually uses.

If your ISP authenticates over PPPoE:

pppoe-client.rsc
# Create the PPPoE client on the WAN-facing interface
/interface pppoe-client
add name=pppoe-wan interface=ether1 user=your_isp_username \
password=your_isp_password add-default-route=yes \
use-peer-dns=yes disabled=no
# PPPoE overhead eats bytes, so drop your MTU to avoid fragmentation issues
/interface pppoe-client set [find name=pppoe-wan] max-mtu=1492 max-mru=1492

If your ISP just hands out DHCP instead (common on some fiber setups even without PPPoE):

dhcp-client.rsc
/ip dhcp-client
add interface=ether1 disabled=no add-default-route=yes use-peer-dns=yes

Either way, the interface facing your ISP is now exposed to the actual internet, not sitting behind the ISP box’s NAT anymore. That means the router itself needs a real firewall, not the “good enough” defaults. The rules below assume PPPoE, so if you went the DHCP route, swap every pppoe-wan for ether1:

wan-firewall.rsc
/ip firewall filter
# Allow established/related traffic back in, drop invalid packets
add chain=input connection-state=established,related action=accept
add chain=input connection-state=invalid action=drop
# Allow only what you actually intend to expose on WAN (example: WireGuard)
add chain=input protocol=udp dst-port=51820 in-interface=pppoe-wan action=accept
# Everything else hitting the router itself on WAN gets dropped
add chain=input in-interface=pppoe-wan action=drop

And outbound NAT so your LAN devices can actually reach the internet through the new public IP:

masquerade-nat.rsc
/ip firewall nat
add chain=srcnat out-interface=pppoe-wan action=masquerade

The MTU line above is not optional decoration. It’s the single most common “some websites just don’t load” bug after a bridge-mode migration. PPPoE adds 8 bytes of overhead, and if your MTU is still sitting at the Ethernet default of 1500 while your PPPoE interface is doing 1492, larger packets get silently dropped by whatever middlebox doesn’t like fragmentation, and you get a network that pings fine but half-loads pages that pull in bigger assets. Pair the MTU fix with MSS clamping so TCP sessions negotiate correctly through the tunnel:

mss-clamp.rsc
/ip firewall mangle
add chain=forward tcp-flags=syn tcp-mss=!0-1452 protocol=tcp \
out-interface=pppoe-wan action=change-mss new-mss=1452

If you’d rather run something x86-based instead of RouterOS for this role, the tradeoffs are covered in pfSense vs OPNsense in 2026, but for a fiber handoff like this, a small MikroTik box is cheaper, quieter, and honestly overkill-proof for anything short of gigabit-plus symmetric fiber.

What Breaks, and Why It’s Not a Mystery

A few things reliably go sideways after you take over routing, and none of them mean you did something wrong.

IPTV and VoIP stop working. If your ISP bundles a TV box or a phone line through the same connection, it was almost certainly riding a separate tagged VLAN that the ISP router was quietly handling for you. You’ll need to find that VLAN ID (check the ISP box’s config before you touch anything, or ask support) and either replicate the tag on your MikroTik’s bridge, or leave one dedicated port bridged straight through from the ONT for that traffic only.

Inbound stuff just stops. If port forwards, VPN connections, or anything expecting to be reached from outside suddenly go quiet, go back and check whether you’re behind CGNAT. Bridge mode doesn’t rescue you from a shared public IP; that’s an ISP-side allocation problem, and the fix is a static IP add-on or an outbound-only relay like Pangolin, never a firewall tweak.

Remote management from your ISP disappears. TR-069 style auto-provisioning lives on the box you just demoted, so once it’s bridged, your ISP loses its remote hooks into your network. That’s mostly a feature, right up until you need a support call and they can’t see anything on their end and start asking you to read out settings over the phone.

IPv6 needs its own line item. Prefix delegation has to be configured explicitly on the MikroTik now, it won’t just show up the way it did when the ISP box handled everything transparently. Don’t assume it’s working just because IPv4 is fine.

The Order You Actually Do This In

Confirm bridge mode is available before you buy anything. There’s no point owning a MikroTik box that’s stuck behind double NAT because it turns out your ISP flatly refuses bridge mode on your specific plan tier.

Get your PPPoE username and password in hand first (or confirm it’s DHCP), because once the ISP box is bridged, its login screen may no longer have that information anywhere useful, and some ISPs make you dig through account portals or an app to find it.

Do the actual swap at a time nobody in the house needs the internet, because there will be a gap while you flip the ISP box into bridge mode, and then a smaller gap while the MikroTik negotiates its own connection. Ten minutes if you’re prepared, longer if PPPoE authentication is being cranky that day.

Back up the ISP box’s original configuration before you change anything. Most admin panels have an export or backup option buried in a settings tab. If bridge mode turns out to be a disaster, or your ISP support insists on reverting it for a service call, you want to click “restore,” not remember every checkbox you flipped from memory at 11 PM.

Once it’s running, the rest of the network, VLANs, firewall segmentation, WireGuard, is exactly what the MikroTik home lab guide already walks through. You’ve just cleared the one obstacle that guide never mentions: getting your own router into a position where any of that advice actually matters.


Share this post on:

Send a Webmention

Written about this post on your own site? Send a webmention and it'll show up above once verified.


Previous Post
dbt-core for Self-Hosters: SQL With Tests, Without dbt Cloud
Next Post
SigNoz vs Grafana LGTM Stack

Discussion

Powered by Garrul . Sign in with GitHub or Google, or post anonymously.

Related Posts