MikroTik IPv6 Firewall Configuration: Secure Dual-Stack Networks

IPv6 changes the security model of a MikroTik network. In a typical IPv4 deployment, private LAN hosts are often hidden behind source NAT. IPv6 is designed for end-to-end addressing, so clients may have globally routable addresses and can be reached from the internet unless the router’s firewall explicitly blocks unsolicited inbound traffic. Enabling IPv6 without building an IPv6 firewall is therefore not a safe dual-stack deployment.

This guide explains how to secure both IPv4 and IPv6 on MikroTik RouterOS 7. It covers the difference between protecting the router and protecting forwarded clients, a practical stateful IPv6 ruleset, essential ICMPv6 handling, DHCPv6 prefix delegation, controlled inbound services, troubleshooting, and a safe rollout process. The examples use interface lists named LAN and WAN; adapt interface names, prefixes, and permitted services to your topology before applying them.

Important: the rules below are a baseline template, not a universal drop-in configuration. Test from a local console or a reliable out-of-band management path, use Safe Mode for remote changes, and confirm that your provider’s IPv6 addressing and prefix-delegation design match the example.

Why Dual-Stack Networks Need Two Firewalls

IPv4 and IPv6 are separate protocol families in RouterOS. IPv4 filter rules under /ip firewall filter do not automatically protect IPv6 traffic. IPv6 rules must be configured separately under /ipv6 firewall filter. An IPv4 firewall that drops unsolicited WAN traffic can coexist with an IPv6 path that permits it if the IPv6 rules are missing or too permissive.

Do not assume NAT provides IPv6 security. Many IPv6 networks do not use NAT66, and a global IPv6 address on a client is not inherently a security problem. The security boundary should be the stateful firewall: allow return traffic for sessions initiated from trusted networks, explicitly allow the inbound services you intend to expose, and drop other unsolicited traffic. For the separate IPv4 translation model, see our MikroTik RouterOS 7 NAT guide.

A secure dual-stack policy should provide equivalent outcomes for both families:

• Allow established and related traffic so legitimate sessions and their replies work.
• Drop invalid packets.
• Permit the ICMP and ICMPv6 messages needed for network operation and diagnostics.
• Allow management access to the router only from trusted management networks.
• Allow LAN clients to initiate the outbound traffic they need.
• Allow inbound connections only for explicitly published services.
• Drop unsolicited traffic from the WAN by default.

IPv6 requires extra care because Neighbor Discovery, Router Advertisements, Path MTU Discovery, and other essential functions depend on ICMPv6. A blanket ICMPv6 drop can create failures that look like random connectivity or performance problems. For addressing, routing, and broader RouterOS deployment context, see our complete MikroTik IPv6 configuration guide.

Understand the RouterOS Firewall Chains

RouterOS filter rules are evaluated in order. The first matching terminal action determines what happens to a packet. The three built-in chains have different jobs:

• input: packets addressed to the MikroTik router itself, such as WinBox, SSH, DNS, DHCPv6 client traffic, and routing protocols running on the router.
• forward: packets routed through the MikroTik between networks, such as LAN clients accessing the internet or external users connecting to a published server.
• output: packets generated by the router, such as DNS queries, NTP, package checks, and monitoring traffic.

Protecting only the input chain is not enough. It can secure the router’s management plane while leaving forwarded traffic to LAN clients exposed. Conversely, a restrictive forward chain does not stop an attacker from probing services running directly on the router. Both input and forward policies are required.

Prepare Interface Lists and Address Lists

Using interface lists makes the firewall easier to maintain than hard-coding a WAN interface into every rule. The examples assume you have already created interface lists named WAN and LAN and added the correct physical, VLAN, PPPoE, or tunnel interfaces to them.

/interface/list/print
/interface/list/member/print

Check that the internet-facing interface is in WAN and all trusted client-facing interfaces are in LAN. If you have separate guest, IoT, server, and management VLANs, consider separate lists or address lists so that the policy can distinguish them.

Create an IPv6 address list for the delegated LAN prefix or prefixes. Replace the documentation prefix below with the actual prefix routed to your site:

/ipv6/firewall/address-list
add list=LANv6 address=2001:db8:1234:1::/64 comment="Replace with actual LAN prefix"

2001:db8::/32 is reserved for documentation and must not be used as a production address. If the ISP delegates a larger prefix, add the actual routed client prefixes, such as each VLAN’s /64. Do not put a guessed or temporary prefix in a production allow-list.

If your provider changes the delegated prefix, keep the firewall address list synchronized with the active prefix. A stale source-prefix allow rule can block legitimate clients after a renumbering event. For multi-prefix or multi-WAN deployments, document which prefix belongs to each LAN and uplink.

Protect the MikroTik Router Itself: IPv6 Input Chain

The input policy should accept return traffic, discard invalid packets, allow required ICMPv6, permit DHCPv6 prefix-delegation replies where the MikroTik is a DHCPv6 client, allow management only from trusted sources, and then drop everything else.

The following is a baseline for a router that receives DHCPv6 prefix delegation from its ISP and allows router management from trusted LAN prefixes:

/ipv6/firewall/filter
add chain=input action=accept connection-state=established,related,untracked comment="Allow established, related, untracked"
add chain=input action=drop connection-state=invalid comment="Drop invalid"
add chain=input action=accept protocol=icmpv6 comment="Allow essential ICMPv6"
add chain=input action=accept protocol=udp src-address=fe80::/10 dst-port=546 in-interface-list=WAN comment="Allow DHCPv6 client prefix delegation"
add chain=input action=accept in-interface-list=LAN src-address-list=LANv6 comment="Allow router access from trusted LAN prefixes"
add chain=input action=drop in-interface-list=WAN comment="Drop other input from WAN"
add chain=input action=drop comment="Drop all other input"

Place these rules in the correct order and review any existing rules before adding them. RouterOS does not automatically reorder rules to match this example. If you already have a firewall, merge the logic carefully rather than appending a second terminal drop rule that makes later rules unreachable.

The ICMPv6 accept rule is deliberately broad in this baseline because ICMPv6 carries essential control and error messages. In a hardened environment, you can refine it by type and code after confirming the required Neighbor Discovery, Packet Too Big, Destination Unreachable, Time Exceeded, and Parameter Problem messages for your design. Do not replace it with a blanket ICMPv6 block.

The DHCPv6 client rule is only needed when the MikroTik itself receives prefix delegation as a DHCPv6 client. It accepts UDP destination port 546 from link-local sources arriving on the WAN. If you use a DHCPv6 relay or another provider design, the source and interface conditions may need adjustment. Do not add this rule automatically when the router is not a DHCPv6 client.

The LAN management rule uses the delegated client prefix list. If you manage the router from a dedicated management VLAN, use that VLAN’s prefix instead of allowing every client subnet. Add explicit rules for trusted VPN management sources where appropriate. Avoid exposing WinBox, SSH, or the web interface to the entire internet.

Protect LAN Clients: IPv6 Forward Chain

The forward chain is the critical protection for globally addressed IPv6 clients. A typical client should be able to initiate outbound connections and receive their replies, while unsolicited new connections arriving from the WAN are dropped unless a specific service has been published.

For a simple LAN-to-internet design, the following baseline permits established and related traffic, drops invalid traffic, allows ICMPv6 forwarding, permits new connections sourced from the trusted LAN prefix, and drops everything else:

/ipv6/firewall/filter
add chain=forward action=accept connection-state=established,related,untracked comment="Allow established, related, untracked"
add chain=forward action=drop connection-state=invalid comment="Drop invalid"
add chain=forward action=accept protocol=icmpv6 comment="Allow ICMPv6 forwarding"
add chain=forward action=accept in-interface-list=LAN src-address-list=LANv6 comment="Allow LAN clients to initiate traffic"
add chain=forward action=drop comment="Drop all other forwarded IPv6 traffic"

This is a default-deny example for a simple trusted LAN. It does not create a general inbound allow from the WAN. A new connection arriving from the internet will not match the established/related rule or the LAN-originated rule, so it reaches the final drop.

For networks with multiple security zones, do not treat every interface in LAN as equally trusted. A guest VLAN should not automatically be able to reach management, server, or IoT networks. Add explicit inter-VLAN allow rules for the required source and destination prefixes, then add drops between zones. For example, permit a user VLAN to reach a DNS resolver while blocking access to the router’s management subnet and server management ports.

ICMPv6 forwarding should not be removed simply because it is not an application protocol. Router-to-router error messages, especially Packet Too Big messages used by Path MTU Discovery, are important for reliable end-to-end IPv6 communication. If you later restrict ICMPv6 by type, test large transfers, tunnels, VPNs, and paths with reduced MTUs.

Keep IPv4 and IPv6 Policies Aligned

Dual-stack security is only as strong as the weaker protocol family. Review the IPv4 input and forward chains alongside IPv6 and ensure the same trust boundaries apply. A common IPv4 baseline includes established/related acceptance, invalid drops, trusted LAN management, LAN-originated outbound traffic, and a default WAN drop.

Example IPv4 baseline (adapt to existing NAT, VPN, port-forward, and management rules):

/ip/firewall/filter
add chain=input action=accept connection-state=established,related,untracked comment="Allow established, related, untracked"
add chain=input action=drop connection-state=invalid comment="Drop invalid"
add chain=input action=accept protocol=icmp comment="Allow required ICMP"
add chain=input action=accept in-interface-list=LAN comment="Allow router access from LAN (restrict further as needed)"
add chain=input action=drop in-interface-list=WAN comment="Drop other input from WAN"
add chain=input action=drop comment="Drop all other input"

add chain=forward action=accept connection-state=established,related,untracked comment="Allow established, related, untracked"
add chain=forward action=drop connection-state=invalid comment="Drop invalid"
add chain=forward action=accept in-interface-list=LAN comment="Allow LAN-originated forwarding (restrict by zone as needed)"
add chain=forward action=drop comment="Drop all other forwarded IPv4 traffic"

This minimal IPv4 example intentionally does not include a FastTrack rule, NAT rule, VPN exceptions, port forwards, or inter-VLAN policy. Preserve the existing rules required by your design. If you add FastTrack, place it only after understanding which traffic needs queues, accounting, policy routing, IPsec, or other processing that FastTrack may bypass.

For a real deployment, do not simply copy the broad IPv4 LAN input rule if the LAN includes untrusted devices. Restrict router management to an administrator subnet or management VLAN. Ensure IPv4 port-forward rules have corresponding forward-chain permits before the final drop. IPv4 and IPv6 should have intentional, documented differences only where the services or addressing model require them.

Why ICMPv6 Must Not Be Blocked Blindly

ICMPv6 is not just the IPv6 version of ping. It is part of the protocol’s operation. Neighbor Discovery uses ICMPv6 messages to resolve link-layer addresses and maintain local reachability. Router Solicitation and Router Advertisement messages support host configuration. Packet Too Big messages allow Path MTU Discovery to work across links with different MTUs. Destination Unreachable and Time Exceeded messages support error reporting and diagnostics.

Common ICMPv6 functions include:

• Neighbor Solicitation and Advertisement: local address resolution and duplicate-address detection.
• Router Solicitation and Advertisement: router discovery and SLAAC configuration.
• Packet Too Big: signals that a packet must be sent with a smaller size.
• Destination Unreachable: reports delivery failures.
• Time Exceeded: used by traceroute and hop-limit processing.
• Echo Request and Reply: ping diagnostics.

Some ICMPv6 traffic is link-local and is not routed, while other ICMPv6 errors travel across routed paths. A simplistic rule that drops all ICMPv6 from WAN can break PMTUD or other IPv6 functions. Start with the official MikroTik baseline and refine only when you understand the required message types and their direction.

DHCPv6 Prefix Delegation and WAN Access

Many ISPs delegate an IPv6 prefix to the customer router using DHCPv6 Prefix Delegation (PD). The router then assigns /64 subnets to LAN VLANs and advertises them to hosts through Router Advertisements. The firewall must allow the DHCPv6 client exchange required to receive or renew the delegated prefix.

Inspect the DHCPv6 client and address state:

/ipv6/dhcp-client/print detail
/ipv6/address/print detail
/ipv6/route/print detail

Verify that the delegated prefix is active, the intended LAN interfaces have addresses or advertised prefixes, and a default route is present. If clients receive addresses but cannot reach the internet, check the route and forward chain before changing address assignment.

Router Advertisements and Neighbor Discovery operate on the local link. Do not forward link-local multicast as though it were ordinary internet traffic. Keep the relevant router advertisements and neighbor discovery behavior scoped to the correct LAN interface or VLAN, and avoid accidentally advertising a prefix on the WAN or an untrusted segment.

Safely Publish IPv6 Services

IPv6 services are usually published by allowing the required inbound traffic to the server’s global address through the forward chain. This is different from IPv4 port forwarding with destination NAT. In a normal globally addressed IPv6 deployment, the server can have a global address and the router filters access to it without translating the destination.

For example, if a web server has a stable address in your delegated prefix, add a narrowly scoped permit before the final forward drop. Replace the example address and interface list with the actual server address and path:

/ipv6/firewall/filter
add chain=forward action=accept in-interface-list=WAN dst-address=2001:db8:1234:10::20 protocol=tcp dst-port=443 connection-state=new comment="Allow HTTPS to published server"

This rule is only an example. It allows new HTTPS connections to that one destination address and port. Ensure the server host firewall is also configured, the service is patched, and the server does not expose unrelated ports. Add corresponding rules for other services only when needed. If you use a reverse proxy, VPN gateway, or load balancer, publish that endpoint rather than opening every LAN host.

For a server with a dynamically changing delegated prefix, do not rely on a hard-coded address that will become stale after renumbering. Use a stable addressing plan within the delegated prefix, update the rule through automation, or use a design that keeps the server’s firewall identity synchronized with the active prefix.

Do not add a blanket rule that accepts all new traffic from WAN to LAN. That defeats the default-deny policy. Also remember that an IPv6 allow rule in the router does not replace the server’s local firewall.

Address Lists, Logging, and RAW Filtering

IPv6 address lists are maintained separately from IPv4 address lists. A list with the same name in both families is not one shared object. Add the actual client prefixes, management prefixes, and any blocked prefixes under /ipv6 firewall address-list.

Because an IPv6 host can use multiple addresses within its subnet, including temporary privacy addresses, blocking a single host address may not reliably block that device. For policy decisions, use the correct subnet or a more appropriate identity mechanism, such as VLAN membership, a managed endpoint address plan, or an upstream access-control system. Avoid blocking an entire shared /64 if that would affect unrelated devices.

Logging is useful during rollout, but logging every dropped packet can overwhelm the router and fill logs during scans or attacks. Start with counters and limited, rate-controlled logging for specific rules. Use distinctive log prefixes so that denied input, denied forwarding, and invalid packets can be separated during analysis.

The IPv6 RAW table runs before connection tracking. It can be useful for dropping known unwanted traffic early, but RAW rules do not have connection-state matchers. Do not add broad RAW drops without understanding whether the rule could also block return traffic or essential ICMPv6. Begin with a correct filter policy; introduce RAW filtering only for a defined operational reason.

Troubleshoot Common IPv6 Firewall Problems

Clients receive IPv6 addresses but cannot browse

• Confirm the delegated prefix and default route are active.
• Check that the LAN prefix in the IPv6 address list matches the actual prefix assigned to clients.
• Inspect forward-chain counters to see whether outbound packets hit the LAN allow rule or the final drop.
• Confirm ICMPv6 Packet Too Big messages are not being blocked.
• Test DNS separately from raw IPv6 reachability.

IPv4 works but IPv6 is unreachable

Check the IPv6 firewall independently; IPv4 rules do not protect or permit IPv6. Confirm that the ISP provides IPv6 service, DHCPv6-PD or static routing is correct, Router Advertisements are configured on the LAN, and a default IPv6 route exists.

WinBox or SSH access stops after enabling the firewall

The management source may not match the allowed prefix, or the management interface may not be in the expected interface list. Use console or out-of-band access to inspect the input chain and counters. Add a narrowly scoped management permit before the final drop. Do not solve this by opening management to the entire WAN.

Some websites load, but large downloads or VPNs stall

This can indicate a Path MTU Discovery problem. Check whether ICMPv6 Packet Too Big messages can reach the originating host. Review tunnel MTU, MSS handling, and any ICMPv6 type-specific rules. Avoid using an arbitrary MSS clamp as a substitute for fixing blocked ICMPv6 errors.

Inbound IPv6 scans reach internal hosts

Inspect the forward chain and rule order. Look for a broad WAN-to-LAN accept rule, an overly broad interface list, a permissive final policy, or an earlier jump/accept that bypasses the intended drop. Confirm that every published-service exception is destination- and port-specific.

Firewall counters do not increase as expected

Check whether traffic uses another router, a bridge path, a VPN, or a different interface list. Verify the actual ingress interface and packet direction. Use /ipv6 firewall filter print stats and inspect rule order and counters while generating a controlled test flow.

Neighbor Discovery or SLAAC stops working

Review ICMPv6 handling on the local LAN, Router Advertisement settings, bridge/VLAN membership, and any RAW rules. Neighbor Discovery is link-local and depends on correct Layer 2 behavior as well as firewall policy.

Validate and Deploy the Ruleset Safely

Before deploying a firewall change remotely, create a backup and export the current configuration. Use RouterOS Safe Mode when changing rules over the same connection that the rules may interrupt. Keep a local console, serial connection, or separate management path available for critical routers.

Useful inspection commands include:

/ipv6/firewall/filter/print detail
/ipv6/firewall/filter/print stats
/ipv6/firewall/address-list/print
/ipv6/dhcp-client/print detail
/ipv6/address/print detail
/ipv6/route/print detail
/interface/list/member/print
/log/print where topics~"firewall"

Test from both sides of the firewall:

1. From a LAN client, verify IPv6 address assignment, default gateway, DNS resolution, and outbound HTTPS.
2. Verify ping and traceroute behavior, while remembering that remote hosts may intentionally filter echo requests.
3. From an external network, confirm that router management ports are not reachable unless explicitly allowed.
4. Scan or test a LAN server from outside and confirm that only the explicitly published ports are reachable.
5. Test large transfers and VPN traffic to detect Path MTU Discovery issues.
6. Check rule counters and logs to confirm that expected traffic matches the intended allow rules and unsolicited traffic reaches the drop rules.
7. Repeat the same tests over IPv4 and IPv6 so that policy differences are intentional.

When adding a new exception, place it before the relevant final drop, constrain it by source, destination, protocol, and port, and document why it exists. Re-test after every change. Do not leave temporary broad permits enabled after troubleshooting.

Frequently Asked Questions

Does IPv4 firewall protect IPv6 on MikroTik?

No. RouterOS maintains separate IPv4 and IPv6 firewall rule sets. Configure and maintain both families for a dual-stack network.

Should I use NAT66 to protect IPv6 clients?

Usually not. NAT is not a substitute for a firewall. Use stateful IPv6 filtering to block unsolicited inbound connections while allowing legitimate outbound sessions and their replies. Apply translation only when a specific network design requires it.

Should I drop all ICMPv6 traffic from the WAN?

No. ICMPv6 carries essential error and control messages, including Packet Too Big messages required for Path MTU Discovery. Use the MikroTik baseline and refine ICMPv6 types only when you understand the protocol requirements.

What is the difference between input and forward in IPv6 firewall?

Input protects services running on the MikroTik itself. Forward protects devices and networks routed through the MikroTik. A secure deployment needs both.

How do I allow a public IPv6 web server?

Add a narrowly scoped forward-chain rule that permits the required TCP port to the server’s global IPv6 address from the WAN. Keep the default drop for all other unsolicited inbound traffic and maintain the server’s own host firewall.

Why does IPv6 work on some LAN devices but not others?

Check the advertised prefix, VLAN membership, Router Advertisements, client address configuration, and whether the firewall’s source-prefix allow list includes the subnet used by each device. Multi-VLAN networks need a deliberate prefix and policy for every segment.

Conclusion

A secure MikroTik dual-stack network needs explicit IPv4 and IPv6 firewall policies. IPv6 clients may have globally reachable addresses, so the forward chain must block unsolicited inbound sessions by default while allowing only deliberate service exceptions. Protect the router separately with the input chain, permit essential ICMPv6, handle DHCPv6 prefix delegation correctly, and keep management access restricted to trusted networks. Build the policy around interface lists and real delegated prefixes, then validate it from both inside and outside the network. The result is a dual-stack deployment that preserves IPv6 functionality without leaving internal devices exposed.

Official MikroTik References

• MikroTik RouterOS Manual: Firewall Filter
• MikroTik: Building Advanced Firewall
• MikroTik RouterOS Manual: Connection Tracking
• MikroTik RouterOS Manual: Address Lists

---

Check our list of MikroTik guides