PYUR Fiber on a MikroTik CCR2004-1G-12S+2XS (and the IKEA Gateway That Broke My IPv6)

I finally got fiber at home this year, and like most people who run their own router I went looking for a MikroTik-specific writeup on getting PYUR’s fiber product working — and mostly came up empty. Plenty of guides exist for Telekom, htp, and Deutsche Glasfaser, all built around PPPoE and a specific VLAN ID, but PYUR turned out to work completely differently. On top of that, I ran into a genuinely nasty IPv6 gremlin a couple of days after going live that took way longer to track down than it should have. This post covers both: how to actually get a MikroTik CCR2004-1G-12S+2XS talking to a PYUR ONT, and the rogue-router saga that came after.

TL;DR: PYUR fiber in Germany hands out both IPv4 and IPv6 via plain DHCP straight off the ONT — no PPPoE, no VLAN tagging needed on my line. That part was easy. What wasn’t easy was tracking down why my IPv6 kept falling over, which turned out to be an old IKEA smart-home gateway on my LAN happily sending its own Router Advertisements and confusing every device on the network, including my MikroTik. The fix was to explicitly trust Router Advertisements only from the ONT-facing interface and drop them from everywhere else.

The setup

• ISP: PYUR fiber (Germany)
• ONT: provided by PYUR, plain Ethernet handoff
• Router: MikroTik CCR2004-1G-12S+2XS (RouterOS 7.x)
• Uplink: ONT → the router’s single 1G RJ45 port (ether1 in my config below — adjust to whatever port you actually used)

Unlike a lot of the Telekom/Deutsche-Glasfaser writeups floating around, which all revolve around PPPoE and a specific VLAN ID, PYUR’s fiber line didn’t need any of that for me. Plug the ONT into the router, bring the interface up, and both a DHCPv4 client and a DHCPv6 client get you online. No 802.1Q tagging, no PPP credentials.

If your line does need a VLAN, it’s the same idea below, just put the DHCP clients on a VLAN interface on top of ether1 instead of on ether1 directly.

Step 1 — IPv4 over DHCP

Nothing exotic here — a standard DHCP client on the WAN-facing interface:

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

I keep use-peer-dns=no because DNS resolution happens on a box in my homelab, not on the router itself — leave it at the default if you’re happy using PYUR’s resolvers.

Step 2 — IPv6 over DHCPv6 (with prefix delegation)

PYUR doesn’t just hand out a single address — it delegates a prefix via DHCPv6-PD that you then subnet across your own LANs:

/ipv6 dhcp-client
add interface=ether1 pool-name=pyur-pd pool-prefix-length=56 \
    request=address,prefix add-default-route=yes use-peer-dns=no

Adjust pool-prefix-length to whatever your own delegation looks like — check /ipv6 dhcp-client print detail after the client picks up a lease to see exactly what you were handed, mine came back as a /56.

Then hand a /64 out of that pool to the LAN bridge and let RouterOS advertise it:

/ipv6 address
add address=::1 interface=bridgeLAN from-pool=pyur-pd advertise=yes

/ipv6 nd
add interface=bridgeLAN advertise-dns=yes advertise-mac-address=yes \
    dns-servers=<homelab-resolver-ipv6>

(Swap <homelab-resolver-ipv6> for the actual address of your homelab DNS box — mine lives on a separate server, not on the router.)

At this point IPv4 and IPv6 both worked. For about a day.

The problem: IPv6 randomly falling over

A day or two in, IPv6 started acting up — devices losing their default route, some LAN clients pinging out fine while others timed out, and every so often what looked like a second, completely different gateway showing up in /ipv6 neighbor print. IPv4 was mostly fine but occasionally got weird too, which made it even more confusing to diagnose since it pointed away from “pure IPv6 problem.”

The DHCPv6 client on the router itself would also intermittently drop its lease or stop renewing properly, which was the most misleading symptom — it made it look like a PYUR-side or DHCPv6-client bug rather than something happening on my own LAN.

Finding the culprit

/ipv6 neighbor print showed a router I didn’t recognize advertising itself with its own prefix. A quick capture with Wireshark on a laptop plugged into the LAN (filtering on icmpv6.type == 134, i.e. Router Advertisements) confirmed it: there were two sources sending RAs onto my network — the ONT/PYUR side, which is expected, and an old IKEA smart-home gateway sitting on the same LAN.

It turned out this wasn’t the gateway malfunctioning — it was a feature. IKEA rolled out Matter and Thread support to their smart-home gateways, and a Thread Border Router’s whole job is to bridge the Thread mesh (which is IPv6-native) onto your regular LAN. To do that properly it needs to act as an actual router on your network — which means it starts sending Router Advertisements, completely unprompted, to make itself known as a router to the rest of the segment. Mine had quietly picked this up in a firmware update, with zero indication in the app that it had just turned itself into a second router on my LAN.

The packet capture confirmed it, and unplugging the gateway made the symptoms disappear immediately. With two routers on the same L2 segment both sending RAs, LAN clients (and at times the MikroTik’s own IPv6 stack) ended up with conflicting default gateways and conflicting prefixes, which lines up with exactly the flakiness I was seeing.

This is a classic rogue-RA problem: any device on an IPv6 LAN can announce itself as a router, and everyone else has to just believe it. There’s no authentication in Neighbor Discovery by default.

The fix: only trust RA from the ONT

Rather than hunting down every random IoT gadget that might decide to announce itself as a router, I set up a proper interface list and told the router to only accept Router Advertisements coming in from the WAN side (i.e. from the ONT). Everything else gets dropped.

First, make sure WAN and LAN are in separate interface lists (and that the WAN port isn’t accidentally a member of your LAN bridge — worth double-checking if you started from a default configuration):

/interface list
add name=WAN
add name=LAN

/interface list member
add interface=ether1 list=WAN
add interface=bridgeLAN list=LAN

Then drop any Router Advertisement that isn’t coming in on the WAN list, as early as possible in the raw table:

/ipv6 firewall raw
add chain=prerouting protocol=icmpv6 icmp-options=134:0-255 \
    in-interface-list=!WAN action=drop \
    comment="Only the ONT is allowed to send Router Advertisements"

If your RouterOS build doesn’t like matching in the raw table, the same rule works in the regular filter table:

/ipv6 firewall filter
add chain=input protocol=icmpv6 icmp-options=134:0-255 \
    in-interface-list=!WAN action=drop comment="Drop rogue RA (input)"
add chain=forward protocol=icmpv6 icmp-options=134:0-255 \
    in-interface-list=!WAN action=drop comment="Drop rogue RA (forward)"

A couple of things worth calling out:

• Don’t blanket-block ICMPv6. IPv6 relies on ICMPv6 for neighbor discovery, path MTU discovery, and address configuration — this rule only matches type 134 (Router Advertisement), nothing else.
• If your WAN interface and LAN bridge ever end up on the same physical bridge (flat network), a routed firewall rule like this won’t stop a rogue device from reaching other LAN clients directly at layer 2 — it only protects the router itself. Keeping WAN and LAN as genuinely separate interfaces/bridges is what makes this fix airtight rather than a partial mitigation.
• Restart the IPv6 DHCP client (/ipv6 dhcp-client release then re-enable, or just disable/enable the entry) after applying this so it re-negotiates cleanly instead of sitting on a possibly-confused lease.

Since adding those two rules, the phantom router has never shown back up in /ipv6 neighbor print, and the DHCPv6 client has been rock solid.

Lessons learned

• PYUR’s fiber access is refreshingly simple compared to the PPPoE/VLAN dance a lot of other German ISPs still require — a plain DHCPv4 + DHCPv6-PD client on the WAN interface is all you need.
• IPv6 has no equivalent of “just don’t plug a second router into the switch” — any device on your LAN can send Router Advertisements, and your other devices will believe it. That now includes smart-home hubs quietly turning into Thread Border Routers after a firmware update, with no warning that they’ve become a router on your network.
• If IPv6 (or even IPv4) starts behaving inconsistently on a network with more than one router-capable box plugged in — including random smart-home hubs — check /ipv6 neighbor print and a Wireshark capture for ICMPv6 type 134 before you go blaming your ISP.
• Whitelisting Router Advertisements to only the interface facing your actual upstream router is cheap insurance against this happening again with the next gadget you plug in.