Hey all,

I spent tonight debugging why my Gluetun VPN containers refused to start after an array restart with an IPv6 error, even though IPv6 was working perfectly an hour before. Turns out this is the same underlying bug that's been biting people for years across different Unraid versions, and I think the root cause deserves its own clear explanation because the existing threads dance around it without nailing it down.

The symptom

After any array restart (or reboot), IPv6 stops working. Containers that need IPv6 fail. VMs lose their IPv6 addresses or connectivity. Matter/Thread devices go offline. The host has no IPv6 default route even though your router is advertising one correctly.

The root cause, as simply as I can put it

When Docker starts, it enables IPv6 packet forwarding on the host:

net.ipv6.conf.all.forwarding = 1

This is a Linux kernel-level thing — Docker needs it so containers can route traffic. The problem is that the Linux kernel treats any host with forwarding=1 as a router, and routers don't listen to Router Advertisements from other routers. So the kernel silently stops accepting RAs on all interfaces, which means your IPv6 default route (learned from your gateway via RA) disappears and never comes back.

You can verify this yourself:

sysctl net.ipv6.conf.br0.accept_ra

If it shows 0, that's your problem.

Why it worked before the reboot

Timing. If Docker was already running when you first configured IPv6, the existing RA-learned route might have still been in the routing table. It just doesn't survive a restart because the startup sequence goes: network comes up → RA installs default route → Docker starts → forwarding=1 kills RA acceptance → route expires → never renewed.

Why Unraid's rc.docker doesn't catch this

rc.docker actually does check for an IPv6 default route before deciding whether to start Docker with --ipv6:

if [[ -n $(ip -6 route show to default dev $PORT) ]]; then
    DOCKER_OPTS="--ipv6 --fixed-cidr-v6=$DOCKER0 $DOCKER_OPTS"

But this creates a chicken-and-egg problem. The route exists when Docker starts, so Docker gets --ipv6. Then Docker enables forwarding, which kills the route. Next reboot, the route might not be there in time, so Docker starts without --ipv6, and now the Docker bridge network doesn't have IPv6 either.

How this cascades to Gluetun

If you run Gluetun (https://github.com/qdm12/gluetun) with dual-stack WireGuard (both IPv4 and IPv6 in WIREGUARD_ADDRESSES), this bites extra hard.

Gluetun checks IPv6 support at startup by looking at the routing table inside its container namespace. If the Docker network doesn't have IPv6 (because rc.docker didn't see a default route and skipped --ipv6), Gluetun finds no IPv6 routes and refuses to start:

ERROR VPN settings: Wireguard settings: interface address is IPv6 but IPv6 is not supported: address 2a07:b944::2:2/128

This is logged as "IPv6 is not supported after searching N routes" — it's not a Gluetun bug, it's just reporting what it sees.

Any container using Gluetun's network namespace (qbittorrent, prowlarr, etc.) then also fails to start because the network namespace doesn't exist.

Related Gluetun issues:

- #1597 — interface address is IPv6 but IPv6 is not supported (https://github.com/qdm12/gluetun/issues/1597) (May 2023)

- #2713 — IPv6 suddenly no longer working (https://github.com/qdm12/gluetun/issues/2713) (Feb 2025)

The fix

One line in /boot/config/go:

sysctl -w net.ipv6.conf.br0.accept_ra=2

accept_ra=2 means "accept Router Advertisements even when forwarding is enabled."

This is the standard Linux fix for any host that needs to both forward packets and receive RAs — which is exactly what an Unraid box running Docker is.

This is a known upstream Docker bug

This was reported to Docker in March 2022: docker/for-linux#1373 (https://github.com/docker/for-linux/issues/1373) — "Docker sets forward=1 but not accept_ra=2 when enabling IPv6." Still not fixed as of today.

Unraid threads about the same underlying issue

- IPv6 RA inside UnRAID VM not accepted (https://forums.unraid.net/topic/138717-ipv6-ra-inside-unraid-vm-not-accepted/) (May 2023, Unraid 6.11.5)

- Docker IPv6 issues on 7.0.1 (https://forums.unraid.net/topic/188533-docker-ipv6-issues-on-701/) (June 2025)

- The state of ipv6 in unRaid's docker (https://forums.unraid.net/topic/193868-the-state-of-ipv6-in-unraids-docker/) (October 2025)

- [7.2.0] ipv6 networking to VMs no longer functional (https://forums.unraid.net/bug-reports/stable-releases/720-ipv6-networking-to-vms-no-longer-functional-r4136/) (2026)

The 7.2.1 fix ("load br_netfilter and set IPv6 FORWARD policy to ACCEPT") addresses the ip6tables side of things, but not the RA acceptance problem. They're related but separate issues.

Suggestion for LimeTech

Could rc.docker add sysctl -w net.ipv6.conf.$PORT.accept_ra=2 right after enabling IPv6 forwarding? That would fix this for everyone without needing manual go file edits. It's a one-liner and it's what every other Docker-on-Linux guide recommends.

Running Unraid 7.2.5 / OPNsense gateway with SLAAC / Gluetun WireGuard dual-stack.

Edited May 12May 12 by Samsonight
gluetun reference

Update: Two More Root Causes Found (MLD Snooping + rc.docker Bugs)

Since the original post about accept_ra=2 fixing RA acceptance when Docker sets forwarding=1, I've found two additional root causes that can independently break IPv6 on Unraid servers. Both are triggered by the same underlying event (Docker enabling IPv6 forwarding on br0), but they manifest differently.

Cause 2: Managed Switch MLD Snooping Filters IPv6 Multicast

This one is subtle and took a while to track down. Even with accept_ra=2 set, the server may still lose IPv6 because Router Advertisements never reach it at the Ethernet level.

When Docker sets net.ipv6.conf.br0.forwarding=1, the kernel treats br0 as a router interface. Per RFC 2710 Section 5, routers do NOT send MLD (Multicast Listener Discovery) reports — they're expected to already know about multicast groups. There is no sysctl override for this behavior (unlike accept_ra=2 which overrides RA acceptance for forwarding interfaces).

If your server is connected to a managed switch with IGMP/MLD snooping enabled, the switch sees no MLD reports from the server's port. After the membership ages out, the switch stops forwarding IPv6 multicast (including RAs sent to ff02::1) to that port.

Key observation: IPv4 multicast still works fine. IGMP is independent of IPv6 forwarding state, and RFC 4541 Section 2.1.2 exempts 224.0.0.0/24 (including mDNS at 224.0.0.251) from IGMP snooping. So you'll see mDNS working while IPv6 is completely dead — a misleading symptom.

How to confirm

# On the server — you'll see zero IPv6 packets arriving:

tcpdump -i br0 -n icmp6

# Meanwhile IPv4 multicast (mDNS) works fine:

tcpdump -i br0 -n udp port 5353

The fix

Disable IGMP/MLD snooping on the managed switch, at least for the VLAN carrying the server's traffic.

Important: Per-port "unknown multicast flood" settings do NOT help when a multicast querier is active on the network. Once a switch detects a querier, it restricts unknown multicast forwarding to querier ports only — this is documented behavior in the IGMP/MLD snooping specs.

Who is affected

Anyone running Unraid behind a managed switch (any vendor) with MLD snooping enabled. Consumer/unmanaged switches flood all multicast by default, so they're not affected.

Cause 3: Three IPv6 Bugs in rc.docker

This is completely separate from the kernel/network-level issues above. Even if your RAs arrive correctly and accept_ra=2 is set, the Docker custom network for br0 can still end up without working IPv6 due to bugs in /etc/rc.d/rc.docker.

Bug 1: Timing race — IPv6 address detection

Around line 463:

IPV6=$(ip -6 -br addr show scope global primary -deprecated dev $NETWORK | awk '{print $3;exit}')

Docker starts early in the boot process. On SLAAC networks, br0 won't have a global IPv6 address until it receives a Router Advertisement and completes DAD (Duplicate Address Detection) — typically 1-4 seconds after the interface comes up. If Docker starts before this

completes, $IPV6 is empty, the network is created IPv4-only, and it's never updated later.

Suggested fix: Either wait for a global IPv6 address (with timeout), or defer the IPv6 network configuration:

# Wait up to 10 seconds for SLAAC to complete
for i in $(seq 1 20); do
  IPV6=$(ip -6 -br addr show scope global primary -deprecated dev $NETWORK | awk '{print $3;exit}')
  [[ -n $IPV6 ]] && break
  sleep 0.5
done
Bug 2: Link-local gateway discarded

Bug 2: Link-local gateway unusable

Two locations — around line 466 and line 519:

# Line ~466: gateway is collected as fe80::...
GATEWAY6=$(ip -6 route show to default dev $NETWORK | awk '{print $3;exit}')

and

# Line ~519: fe80 is explicitly rejected
[[ -n $GATEWAY6 && ${GATEWAY6:0:4} != fe80 ]] && GATEWAY6="--gateway=$GATEWAY6" || GATEWAY6=

On SLAAC networks (which is the vast majority of IPv6 deployments), the default gateway is always a link-local address (fe80::...). This is correct per RFC 4861. The line 519 conditional drops it, so containers get no IPv6 default route.

However, simply removing the fe80 check at line 519 does NOT work — Docker itself rejects link-local gateways with "no matching subnet for gateway". The gateway must be a global address within one of the configured subnets.

Suggested fix: After collecting the gateway, resolve the link-local address to the router's global address via the NDP neighbor table (same MAC, router flag):

# After line ~466:
GATEWAY6=$(ip -6 route show to default dev $NETWORK | awk '{print $3;exit}')
# Resolve fe80 gateway to router's global address (Docker rejects link-local)
if [[ -n $GATEWAY6 && ${GATEWAY6:0:4} == fe80 ]]; then
  _RMAC=$(ip -6 neigh show dev $NETWORK $GATEWAY6 2>/dev/null | awk '{print $5}')
  if [[ -n $_RMAC ]]; then
    GLOBAL=$(ip -6 neigh show dev $NETWORK | awk -v mac="$RMAC" '$0 ~ mac && $1 !~ /^fe80/ && /router/ {print $1; exit}')
    [[ -n $_GLOBAL ]] && GATEWAY6=$_GLOBAL
  fi
fi

# Line ~519: remove the now-unnecessary fe80 rejection
[[ -n $GATEWAY6 ]] && GATEWAY6="--gateway=$GATEWAY6" || GATEWAY6=

This works because the router's link-local and global addresses share the same MAC in the NDP table. The router flag confirms it's the correct neighbor entry.

Bug 3: Duplicate subnets from ip -6 route

Around line 465:

SUBNET6=$(ip -6 route show dev $NETWORK | sort | awk -v ORS=" " '$1 !~ /^(default|fe80)/ {print $1}' | sed 's/ $//')

ip -6 route show returns each prefix twice — once as proto kernel (from the address assignment) and once as proto ra (from the Router Advertisement). This script doesn't deduplicate them, so docker network create receives duplicate --subnet flags and fails silently.

Suggested fix: Add deduplication:

SUBNET6=$(ip -6 route show dev $NETWORK | awk '$1 !~ /^(default|fe80)/ {print $1}' | sort -u | awk -v ORS=" " '{print}' | sed 's/ $//')

All three are independently capable of breaking IPv6. A complete fix requires addressing all that apply to your setup. Root causes 1 and 2 affect everyone using Docker with IPv6; root cause 3 only matters if you use Docker custom networks with the br0 ipvlan setup.

Edited May 16May 16 by Samsonight
rewording

These issues should be posted in https://product.unraid.net/b/unraid-os-bugs

I'm certain Limetech is already tracking an issue from 2022, would be nice to know where though. This forum section literally says: "Issues with enabling the Docker service on Unraid."

Try entering "accept_ra" in the https://product.unraid.net/b/unraid-os-bugs search box and it returns results not containing the string "accept_ra", I'll leave that windmill for someone else.

And other users wont be searching there as during years of unraid use I've never crossed paths with that site before even by mistake. <3

Or to rephrase it, other threads with the same root cause:

1. Docker IPv6 issues on 7.0.1 (https://forums.unraid.net/topic/188533-docker-ipv6-issues-on-701/ ) — VLAN + SLAAC, IPv6 not working in Docker

2. Docker IPv6 with static address issue (https://forums.unraid.net/bug-reports/stable-releases/docker-ipv6-with-static-address-issue-r3832/) (bug report, May 2025) — accept_ra workaround in comments

3. IPv4+IPv6 breaks sharing for Windows clients (https://forums.unraid.net/topic/189378-ipv4-ipv6-for-unraid-network-interface-breaks-sharing-for-some-windows-clients/) — same sysctl workaround

4. SOLVED: Host access to custom networks no longer works (7.1.0) (https://forums.unraid.net/topic/189927-solved-710-host-access-to-custom-networks-no-longer-works/) — same accept_ra/forwarding sysctl

5. Macvlan: different behavior in Portainer vs native Unraid (https://forums.unraid.net/topic/189797-macvlan-problem-different-behavior-in-portainer-and-native-unraid/) — same workaround

6. Containers started with docker compose disconnecting (https://forums.unraid.net/topic/191376-containers-started-with-docker-compose-disconnecting/) — rc.docker restart as workaround

7. IPv6 RA inside UnRAID VM not accepted (https://forums.unraid.net/topic/138717-ipv6-ra-inside-unraid-vm-not-accepted/) (2023, 6.11.5) — earliest thread, accept_ra=2 in VMs

8. Matter x Docker doesn't work (https://forums.unraid.net/topic/182404-matter-x-docker-doesnt-work/) — IPv6/Thread broken, same root cause

9. 6.12.3: Why is IPv6 disabled on Docker network br0? (https://forums.unraid.net/topic/143280-6123-why-ipv6-is-disabled-on-my-docker-network-custom-network-br0/) — enableIpv6: false on br0

10. 6.12.3: Docker ignores IPv6 addresses (https://forums.unraid.net/bug-reports/stable-releases/6123-docker-ignores-ipv6-addresses-r2586/) (bug report)

11. just curious... broadcast address in config (https://forums.unraid.net/topic/194077-just-curious-why-isnt-there-any-broadcast-address-in-the-config/) — bmartino1 debugging accept_ra/forwarding interaction with rc.docker

12. bmartino1's workaround scripts (https://forums.unraid.net/topic/185359-bmartino1-workaround-scripts-updated/) — "Why not the go file? It's too early in the boot process" — same timing issue you identified

13. Unraid with Matter Thread and UniFi IPv6 issues (https://forums.unraid.net/topic/166559-unraid-with-matter-thread-and-unifi-ipv6-connectivity-issues/page/2/) — accept_ra=2 workaround in comments

14. Getting IPv6 working in Docker Containers (https://forums.unraid.net/topic/88239-getting-ipv6-working-in-docker-containers/) — MikroTik + SLAAC + Docker, earliest comprehensive attempt

@bmartino1 @CraziFuzzy @ken-ji

Edited May 18May 18 by Samsonight

1 hour ago, Samsonight said:

I'm certain Limetech is already tracking an issue from 2022, would be nice to know where though. This forum section literally says: "Issues with enabling the Docker service on Unraid."

Try entering "accept_ra" in the https://product.unraid.net/b/unraid-os-bugs search box and it returns results not containing the string "accept_ra", I'll leave that windmill for someone else.

And other users wont be searching there as during years of unraid use I've never crossed paths with that site before even by mistake. <3

Or to rephrase it, other threads with the same root cause:

1. Docker IPv6 issues on 7.0.1 (https://forums.unraid.net/topic/188533-docker-ipv6-issues-on-701/ ) — VLAN + SLAAC, IPv6 not working in Docker

2. Docker IPv6 with static address issue (https://forums.unraid.net/bug-reports/stable-releases/docker-ipv6-with-static-address-issue-r3832/) (bug report, May 2025) — accept_ra workaround in comments

3. IPv4+IPv6 breaks sharing for Windows clients (https://forums.unraid.net/topic/189378-ipv4-ipv6-for-unraid-network-interface-breaks-sharing-for-some-windows-clients/) — same sysctl workaround

4. SOLVED: Host access to custom networks no longer works (7.1.0) (https://forums.unraid.net/topic/189927-solved-710-host-access-to-custom-networks-no-longer-works/) — same accept_ra/forwarding sysctl

5. Macvlan: different behavior in Portainer vs native Unraid (https://forums.unraid.net/topic/189797-macvlan-problem-different-behavior-in-portainer-and-native-unraid/) — same workaround

6. Containers started with docker compose disconnecting (https://forums.unraid.net/topic/191376-containers-started-with-docker-compose-disconnecting/) — rc.docker restart as workaround

7. IPv6 RA inside UnRAID VM not accepted (https://forums.unraid.net/topic/138717-ipv6-ra-inside-unraid-vm-not-accepted/) (2023, 6.11.5) — earliest thread, accept_ra=2 in VMs

8. Matter x Docker doesn't work (https://forums.unraid.net/topic/182404-matter-x-docker-doesnt-work/) — IPv6/Thread broken, same root cause

9. 6.12.3: Why is IPv6 disabled on Docker network br0? (https://forums.unraid.net/topic/143280-6123-why-ipv6-is-disabled-on-my-docker-network-custom-network-br0/) — enableIpv6: false on br0

10. 6.12.3: Docker ignores IPv6 addresses (https://forums.unraid.net/bug-reports/stable-releases/6123-docker-ignores-ipv6-addresses-r2586/) (bug report)

11. just curious... broadcast address in config (https://forums.unraid.net/topic/194077-just-curious-why-isnt-there-any-broadcast-address-in-the-config/) — bmartino1 debugging accept_ra/forwarding interaction with rc.docker

12. bmartino1's workaround scripts (https://forums.unraid.net/topic/185359-bmartino1-workaround-scripts-updated/) — "Why not the go file? It's too early in the boot process" — same timing issue you identified

13. Unraid with Matter Thread and UniFi IPv6 issues (https://forums.unraid.net/topic/166559-unraid-with-matter-thread-and-unifi-ipv6-connectivity-issues/page/2/) — accept_ra=2 workaround in comments

14. Getting IPv6 working in Docker Containers (https://forums.unraid.net/topic/88239-getting-ipv6-working-in-docker-containers/) — MikroTik + SLAAC + Docker, earliest comprehensive attempt

@bmartino1 @CraziFuzzy @ken-ji

I run a systemctl user script which enables ipv6 forwarding. I've not had issues with unraid nor docker with ipv4/ipv6 due to issues.

#!/bin/bash

# Delay before starting

sleep 10

# Apply sysctl settings

apply_sysctl_settings() {

echo "Applying sysctl settings..."

sysctl -w net.ipv6.conf.all.forwarding=1

sysctl -w net.ipv6.conf.br0.accept_ra=2

echo "Verifying sysctl settings..."

sysctl net.ipv6.conf.all.forwarding

sysctl net.ipv6.conf.br0.accept_ra

}

#run loop

apply_sysctl_settings

script logs:
Script Starting May 17, 2026 13:58.42

Full logs for this script are available at /tmp/user.scripts/tmpScripts/systemctl/log.txt

Applying sysctl settings...

net.ipv6.conf.all.forwarding = 1

net.ipv6.conf.br0.accept_ra = 2

Verifying sysctl settings...

net.ipv6.conf.all.forwarding = 1

net.ipv6.conf.br0.accept_ra = 2

Script Finished May 17, 2026 13:58.52

Full logs for this script are available at /tmp/user.scripts/tmpScripts/systemctl/log.txt

what I have found is uraid really wants ipv6 address via slack to enable ipv6 corectly via its inet scripting systems and if it doesn't get the correct response via the nic it will disable IPv6 as seen with Docker network inspect comands. more due to old and random data and issues with unraid moving away from macvlan to ipvaln due to a macvlan trace bug in early editions of unraid v6.

as in order to use macvlan you need a network nic that supports promiscuous mode...