SERIES
Dual-stack MikroTik, from the ISP to the firewall
Three RouterOS configurations that together describe one working router: native IPv6 delivered by the ISP, a VPN that carries both address families home, and a firewall that turns unsolicited scanning into an automatic block. Written against real hardware on a real Spanish fibre line, not a lab.
Why these three belong together
IPv6 fails in a specific and frustrating way on consumer connections: everything appears configured, and nothing quite works. A prefix arrives but is not delegated onward. Clients get an address but no default route. The VPN connects and the tunnel carries v4 only. Each of these articles fixes one link in that chain, and the reason to read them as a set is that debugging any one of them in isolation usually means discovering you actually have a problem from one of the others.
The shared substrate is RouterOS itself, which is a genuinely different firewall model from the iptables mental picture most guides assume. Address lists are first-class objects that rules both read and write, the RAW table exists to drop traffic before connection tracking spends memory on it, and interface lists let one rule cover a set that changes. All three articles lean on those primitives, so the second and third get considerably easier once the first has introduced them.
The last thing tying them together is that they are dual-stack in the strict sense, not IPv4 configurations with IPv6 added at the end. Every firewall rule appears in both address families, every address list has a v6 counterpart, and the places where the two genuinely differ — no NAT to hide behind, a prefix that can change under you, ICMPv6 that you must not filter blindly — are called out where they matter rather than in a footnote.
Read in this order
The order below is the one that matches how people actually arrive: with a connection that works and a VPN they want to build. If you are starting from a router that has no IPv6 at all, read the second entry first — it is what puts a real delegated prefix on the WAN, which the first one assumes you already have.
Part 1
MikroTik WireGuard VPN: Dual-Stack IPv4/IPv6 Configuration
The piece most readers come for, and the one that states the addressing assumptions the rest of the series exists to satisfy. WireGuard on RouterOS is quick to get working for IPv4 and then quietly incomplete: the tunnel comes up, traffic flows, and every IPv6 destination behind it is unreachable. The article configures both families end to end — interface addressing, allowed-IPs on each side, the firewall rules that let the tunnel talk to the LAN, and the DNS behavior that decides whether a client actually uses the v6 path it now has.
Part 2
MikroTik PPPoE + DHCPv6-PD: Dual-Stack for DIGI Spain
This is where the addresses come from. On DIGI's Spanish fibre the WAN is PPPoE inside a tagged VLAN, and IPv6 arrives as a delegated prefix over DHCPv6 rather than as a single address — which means the router has to request it, keep it, and hand subnets out of it, and the whole thing has to survive the prefix changing. The article covers the VLAN tagging, the PPPoE client, prefix delegation, SLAAC on the LAN side, and the firewall rules that a dual-stack WAN needs before it is safe to leave running.
Part 3
MikroTik Honeypot: Trap & Auto-Block Port Scanners
With the link up and the tunnel working, the last decision is what to do about everything that scans it. The honeypot listens on ports nothing legitimate would touch, and a connection attempt is treated as sufficient evidence: the source lands in an address list, and the RAW table drops its traffic before connection tracking allocates anything for it. Read it last — it is the only one of the three that presumes a working, addressed router, and the only one whose effect you can watch accumulate in a list over the following days.
Where this goes next
Above this sits the web server the router forwards to, which has its own series of decisions to make about who it admits and what it executes. Below it there is not much left: this is the edge. What remains is operational — a prefix that changes after a line event and takes your firewall rules out of alignment with reality, a VPN peer that silently stops rekeying, an address list that grows without bound because nothing ages entries out.
The honeypot article is also the natural bridge to the blocklist tooling used elsewhere on this site. The addresses it collects are the same class of traffic the web-server tarpit sees; running both means the same scanner gets refused at two layers, and the router layer is the one that costs nothing to enforce.
What this series does not cover
There is no routing protocol here — no BGP, no OSPF, no multi-WAN failover. A single-homed residential line with one delegated prefix is a deliberately narrow scope, and it is the scope in which the dual-stack details are hard enough to be worth writing down. There is also no CAPsMAN or wireless chapter: the wireless side of a MikroTik deployment is a separate topic that shares almost none of the reasoning here.